Postgres 9.3 turns messages about implicit indexes and sequences from NOTICE
to DEBUG1 so the tests fail with a default 9.3 server configuration because
the client doesn't get any NOTICE. Fix it by also asking for DEBUG1 messages
from the server when testing against Postgres >= 9.3.
- links updated to the current PG docs, which include the syntax as url
and lists the parameters in a separate chapter
- more evident links to the PG docs
- mutually exclusive use of dsn and **kwargs specified
See ticket #143
The implementation is based on psycopg 2.4, which should be less broken
(zope-wise) of the current one.
Instantiating psycopg2.pool.PersistentConnectionPool now raises a warning.
This should fix ticket #123, #125. The issue of the reset on
set_client_encoding() is still present but that's always been there and I'm no
good at fixing it.
Unfortunately PQcancel blocks, so it's not better than PQgetResult.
It has been suggested to use PQreset in non-blocking way but this would give
the Python program the burden of handling a connection done but not configured
in an unexpected place.
If the network is down, trying to read blocking will hang the process hard
(ctrl-c not working). Send a cancel signal instead (as suggested in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg00903.php) and go
back into a green polling: this should allow a further error (e.g. another
ctrl-c) to break the loop. In this case we cannot assume anything about
the state of the connection, so we close it.
TypeError is the standard Python error raised in this case:
$ python -c "(lambda a: None)(b=10)"
TypeError: <lambda>() got an unexpected keyword argument 'b'
We only used to raise InterfaceError when connect was used without
any parameter at all, so it's hard to think a program depending on
that design. Furthermore the function has always raised (and still
does) OperationalError too, if the bad argument is detected by the
libpq, and that cannot be changed because we can't tell the
difference from a normal connection error.
