This change exposes lower level functions for operating the
(logical) replication protocol, while keeping the high-level
start_replication function that does all the job for you in
case of a synchronous connection.
A number of other changes and fixes are put into this commit.
Introduce ReplicationConnection and ReplicationCursor classes, that
incapsulate initiation of special type of PostgreSQL connection and
handling of special replication commands only available in this special
connection mode.
The handling of stream of replication data from the server is modelled
largely after the existing support for "COPY table TO file" command and
pg_recvlogical tool supplied with PostgreSQL (though, it can also be
used for physical replication.)
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
Makes things more natural as _make has the same signature of the tuple (see
_ctor in CompositeCaster) and is probably more efficient with less
intermediate sequences to build.
Methods execute() and callproc() in DictCursor and RealDictCursor should
call DictCursorBase methods, not _cursor's ones.
Reported by Alexey Luchko on the ML.
Prior to this change, using a extras.connection_factory would not allow
any other cursor to be used on that connection. It was set in stone.
This change allows all cursor options to pass through and override the
connection factory behaviors. This allows a connection_factory to be
dropped into existing code with no disruption.
This change also standardizes the extras.connection_factories to have
the same behavior and all pass through *args and **kwargs.
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.
