Tom Lane wrote:
> "Stephen R. van den Berg" <srb@cuci.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.
>
> 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.
>
>
I really think we need to get something like this into libpq. It's on my
TODO list after notification payloads and libpq support for arrays and
composites. We'll need to come up with an API before we do much else.
cheers
andrew