Re: Protocol 3, Execute, maxrows to return, impact?

Tom Lane wrote:
>"Stephen R. van den Berg" <srb(at)cuci(dot)nl> writes:
>> Then, from a client perspective, there is no use at all, because the
>> client can actually pause reading the results at any time it wants,
>> when it wants to avoid storing all of the result rows. The network
>> will perform the cursor/fetch facility for it.

>[ shrug... ] In principle you could write a client library that would
>act that way, but I think you'll find that none of the extant ones
>will hand back an incomplete query result to the application.

True. But I have written one just now. The language is called Pike,
it's a C/C++/Java lookalike. And I start returning rows as they arrive,
and pause reading from the network when the application wants to pause.

>A possibly more convincing argument is that with that approach, the
>connection is completely tied up --- you cannot issue additional
>database commands based on what you just read, nor pull rows from
>multiple portals in an interleaved fashion.

Interleaved retrieval using multiple portals is not what most libraries
support, I'd guess.
It can be supported at the application layer using multiple cursors, but
that works with my approach as well.

In practice, most applications that need that, open multiple
connections to the same database (I'd think).

The only thing I could imagine is that *if* at the server end, the
notifications that arrive during the retrieval of one long running
Execute, are queued *after* all the data, instead of inserted into
the datastream, then it might be worth doing it differently.

Incidentally, the nice thing about my library is that it automatically
does arguments in binary which are easily processed in binary
(TEXT/BYTEA/ and all those others I mentioned earlier).
It automatically transmits those arguments in binary for *both*
arguments and rowresults; i.e. in one row I can have both text and
binary columns, without the application needing to specify which is
which.
--
Sincerely,
Stephen R. van den Berg.

"If you can't explain it to an 8-year-old, you don't understand it."