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 [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
