Now its state is unmodified, so apart from special-casing creation
and initial population can work unmodified, and all the desired
properties just work (modifiability, picklability...)
Close#886.
I don't know why it returns 0 instead of the right value. At least it
doesn't segfault, so don't skip the test altogether.
The test is unrelated to this branch: will cherry-pick elsewhere (if I
remember it...)
On Py3 subprocessing will actually GC the objects and the FD is open,
resulting in connections closed in different processes.
The behaviour is verified in py 3.4 to 3.7 at least,
It won't work on windows if it's in the script: failing with errors
such as:
AttributeError: 'module' object has no attribute 'process'
or:
Can't get attribute 'process' on <module '__main__' (built-in)>
There's not so much need for a strict convention for static functions.
Leaving some 'psyco_' prefix when the internal function and the
python-exposed function clashed.
The new function keeps together PQconsumeInput() with PQisBusy(), in
order to handle the condition in which not all the results of a sequence
of statements arrive in the same roundtrip.
Added pointer to a PGresult to the connection to keep the state across
async communication: it can probably be used to simplify other code
paths where a result is brought forward manually.
Close#802Close#855Close#856
Have advance_write calling flush itself, advance_read calling is_busy
itself, rather than calling them in the caller and passing the result.
Why we were doing the former on write I don't know. On read the paths
between async and green function was different but they got unified in
the previous commit.
The locking version was used for sync connections, the non-locking one
for green ones. However it only calls non-blocking functions, so it
doesn't really matter releasing the gil. So have only the non-locking
one.
Note that the name are sort of swapped: pq_is_busy() does now what
pq_is_busy_locked() used to do.
