On 31.10.2011 19:09, 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?
Yes, true, although that only works with the simple query protocol. The
extended protocol doesn't allow multi-command 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.
Abandoning all in-flight queries seems quite reasonable to me. You could
send a Sync message between each query to make it easier to track which
query errored.
> 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.
I think a common use for this would be doing multiple inserts or updates
on one go. Like, insert into a parent table, then more details into
child tables. You don't care about getting the results back in that
case, as long as you get an error on failure.
Another typical use case would be something like an ORM that wants to
fetch a row from one table, and details of the same object from other
tables. If it's just 2-3 queries, it's not that difficult to remember in
which order they were issued.
Both of those use cases would be happy with just sending a multi-command
string with PQsendQuery(), because you know the all queries in advance,
but it would be nice to not be limited to simple query protocol...
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com