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.
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.
We don't need to look for stuff implicitly into pg_catalog as all
the builtin ranges are already registered. So just search into
'public' if the schema is not specified.
I was avoiding Numeric to avoid conflicting with the 'numeric'
Postgres type, which is an alias for 'decimal'. But now that there
is a single numeric range I can use the preferred name
Pass a dumps function instead. Allow customizing by either arg passing or
subclassing.
The basic Json class now raises ImportError on getquoted() if json is not
available, thus allowing using a customized Json subclass even when the json
module is not available.
Makes invocation from subclasses and generic code easier.
Code simplified by using default values for keyword arguments
and avoiding needless conversions back and forth between Python and C
strings. Also added connection type check to cursor's init.
Failing to do so was causing the issue reported in ticket #103. The issue
as reported was fixed when SET ISOLATION LEVEL was dropped, but the real
problem wasn't fixed.
The correction is similar to the other one for the other subclasses.
Also added tests for rowcount and rownumber during different fetch styles.
Just in case.
Regression introduced to fix ticket #80. Don't use fetchmany to get the
chunks of values. I did it that way because I was ending up into infinite
recursion calling __iter__ from __iter__: the solution has been the
"while 1: yield next()" idiom.
Actually *it doesn't*: once we iterate the first itersize records, rowcount
is reset to zero. If we want to fix it we need an extra member in the
cursor.
Avoid creating new a new FixedOffsetTimezone instance if one with the
same offset and name has been created before. This will save memory
when returning many rows containing "timestamp with timezone" columns,
and also improves comparability.
