On Mon, 31 Oct 2011, Tom Lane 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?
I remember something about this; I think I concluded that it validated
that receiving multiple results could be done this way.
But this kind of batching can't be used with prepared queries.
> 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.
Can you explain a bit more detail which errors are of most concern, do you
mean full buffers on the client send?
Because the content of the stream going to/from the server does not
change, I wouldn't really expect the semantics to change. For example, the
server cannot even see that the client is behaving in this way. Are there
any 'send' functions that are heavily reliant on some kind of
result/receive state?
I don't disagree with the comments above though, any shift towards
unintelligible behaviour would be very bad.
> 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.
In our UI case, we already have a queue. Because libpq can't pipeline
multiple queries, we have to make our own queue of them anyway.
--
Mark
