A quick release to fix a regression found in psycopg 2.7.2:
- Restored default timestamptz typecasting to Python datetime. Regression introduced in Psycopg 2.7.2 (ticket #578).
Releasing psycopg2 version 2.7.2: a release fixing a host of bugs found in the last 3-4 months.
A quick bugfix release to solve some teething problems with some of the changes introduced in 2.7:
- Ignore None arguments passed to connect() and make_dsn() (ticket #517).
- OpenSSL upgraded from major version 0.9.8 to 1.0.2 in the Linux wheel packages (ticket #518).
- Fixed build with libpq versions < 9.3 (ticket #520).
Finally here! Thank you very much for waiting so long: we have finally released Psycopg 2.7!
- Faster! Helps generating SQL for repeatedly executed statements and faster Unicode decoding.
- Safer! Helps generating dynamic SQL statements with variable table and field names.
- Easier! Use the binary package to avoid the need of C compiler, pg_config, libpq required on the clients.
- Replication! Support for PostgreSQL physical and logical replication.
- Plays-better-with-pgbouncer-at-transaction-pooling-level! This.
we have released psycopg2 version 2.7 beta 2. This version comes two years after the previous major release so it is packed with new features and improvements; among the main points:
Psycopg 2.6.2 has been released. You can get it from:
This is an interim release, packing together one year of bug fixes, before the release 2.7, intended to deliver several new features. Thank you very much to everybody contributing with reports, code, suggestions.
Psycopg 2.6.1 has been released. You can get it from:
We have just released two Psycopg versions: 2.5.5 containing a few bug fixes and 2.6 introducing some new features.
Psycopg 2.5.4 has been released. You can get it from:
This version supports the new jsonb PostgreSQL type out-of-the-box. And of course there are a few bug fixed:
Posted by Daniele Varrazzo on 2014-07-20
Tagged as recipe
Cancelling a long running query from Python is not something that happens automatically: the libpq doesn't react to Python signals so the only way to stop a query is to run a pg_cancel_backend from another process. Killing the Python process won't cancel the query: it will run until completion and then rolled back. This makes working wth long-running query from the Python interpreter somewhat frustrating.