On Jan 4, 2007, at 11:30 PM, Bruce Momjian wrote:
>> No, psql isn't the point: we can certainly make its behavior match
>> the
>> backend's. What I'm wondering about is the effect on random PG-using
>> applications: should we forbid them from sending multiple SQL
>> commands
>> per PQexec (or equivalent in other client library APIs)?
>>
>> Backwards compatibility says no, but you can make some decent
>> arguments
>> for forbidding it anyway.
>
> Yea, I was trying to separate the psql case from the PQexec()
> case. For
> psql, I think it is clear that -c _should_ act like a normal stdin
> query. That would eliminate confusion, and I don't see a large
> loss of
> functionality.
Heh, something I hadn't expected to work:
decibel=# select 1
decibel-# ; select 2
?column?
---------- 1
(1 row)
decibel-# ;
?column?
---------- 2
(1 row)
> The PQexec() case, the problem is we don't know who is using
> multi-statement PQexec() calls, and users can't always add BEGIN/
> END to
> fix them if they are embedded in applications.
>
> What we could do it do both and see what pushback we get during beta.
> We could always revert it before the final release.
There is one (weak) argument for allowing multiple commands in a
single call to the backend; it's going to perform better in an OLTP
environment because of fewer round-trips between the client and server..
Actually, there's some cases there that might not fit well into
wrapping them into a function, ie: multiple selects issued in one go.
So maybe the argument isn't that weak afterall...
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)