On Mon, 31 Oct 2011, Tom Lane wrote: > Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
