Re: Protocol 3, Execute, maxrows to return, impact? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Protocol 3, Execute, maxrows to return, impact?
Date
Msg-id 1116.1215699748@sss.pgh.pa.us
Whole thread Raw
In response to Re: Protocol 3, Execute, maxrows to return, impact?  ("Stephen R. van den Berg" <srb@cuci.nl>)
Responses Re: Protocol 3, Execute, maxrows to return, impact?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Protocol 3, Execute, maxrows to return, impact?  ("Stephen R. van den Berg" <srb@cuci.nl>)
List pgsql-hackers
"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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: WITH RECURSIVE updated to CVS TIP
Next
From: "Dave Page"
Date:
Subject: Re: CommitFest rules