On Mon, Oct 31, 2011 at 7:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 31.10.2011 17:44, Mark Hills wrote:
>>> Could libpq be reasonably modified to allow this?
>
>> I believe it's doable in theory, no-one has just gotten around to it.
>> Patches are welcome.
>
> Can't you do that today with a multi-command string submitted to
> PQsendQuery, followed by multiple calls to PQgetResult?
It's more annoying to to error handling on that, plus it still keeps the
blocking behaviour, just with larger blocks.
> I'm hesitant to think about supporting the case more thoroughly than
> that, or with any different semantics than that, because I think that
> the error-case behavior will be entirely unintelligible/unmaintainable
> unless you abandon all queries-in-flight in toto when an error happens.
> Furthermore, in most apps it'd be a serious PITA to keep track of which
> reply is for which query, so I doubt that such a feature is of general
> usefulness.
Thats why query queue and error handling must happen in protocol
library, not app. And it seems doable, unless the server eats
queries or errors in some situation, breaking simple sequential
query-response mapping. Do you know of such behaviour?
(And several queries in Simple Queriy are known exception,
we can ignore them here.)
Also I would ask for opposite feature: "multiple rows in flight".
That means that when server is sending big resultset,
the app can process it row-by-row (or by 10 rows)
without stopping the stream and re-requesting.
--
marko
PS. I think "full-duplex" is better than "pipeline" here, latter
seems to hint something unidirectional, except yeah,
it is used in HTTP 1.1 for similar feature.