Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> The only argument I can think of is that it allows applications to be
> >> sloppy about parsing a SQL script into individual commands before they
> >> send it. (I think initdb may be guilty of exactly that BTW...) At the
> >> same time you could argue that such sloppiness is inherently a Bad Idea.
>
> > I thought the idea was that psql was going to split multiple -c commands
> > into separate PQexec() calls, so sloppy was OK, and if they want a
> > single transaction, add BEGIN/END to the string.
>
> 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.
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.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +