Tom Lane wrote:
>
> Chris <chris@bitmead.com> writes:
> > What I have in mind is that a new API PQexecStream() doesn't retrieve
> > the results. The tuples are then read back one by one with
> > PQnextObject().
>
> OK, but how does this interact with asynchrononous retrieval? It
> should be possible to run it in a nonblocking (select-waiting) mode.
I didn't know that was a requirement. Well when doing this sort of
stuff you never know what other sources of data they may want
to wait for, so the only way is to have PQfileDescriptor or something,
but I don't think that affects these decisions does it? If they want
async, they are given the fd and select. When ready they call
nexttuple.
> BTW, an earlier proposal for this same sort of thing didn't see it
> as an entirely new operating mode, but just a "limit" option added
> to a variant of PQexec: the limit says "return no more than N tuples
> per PQresult".
As in changing the interface to PQexec?
I can't see the benefit of specifically asking for N tuples. Presumably
behind the scenes it will read from the socket in a respectably
large chunk (8k for example). Beyond that I can't see any more reason
for customisation.
> I looked at that before, and while COPY is certainly ugly as sin, it's
> not clear that it's worth creating cross-version compatibility problems
> to fix it. I'm inclined to leave it alone until such time as we
> undertake a really massive protocol change (moving to CORBA, say).
I'll look at that situation further later. Is there a policy on
protocol compatibility? If so, one way or both ways?
The other comments you made, I have to think about further.