Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > But isn't that like saying that the spec doesn't apply to libpq at all.
> > Why would autocommit not apply but other queries specification apply?
>
> No, you're missing the point. Essentially all the client libraries
> offer their own autocommit behavior on top of what the spec says.
Well, which ones? jdbc (which prevers the server autocommit), ecpg,
odbc (?), and Perl. Anyone else?
> libpq is alone in not having any such client-side logic. So it's not
> a foregone conclusion that we should implement autocommit on/off logic
> on the server side as a substitute for adding it to libpq. We have
> now tried doing it on the server side, and we are finding that we don't
> like the side-effects; so it's time to revisit that decision.
My concern is bloating the API for all languages based on libpq, and
psql and stuff like that. Heck, even pgadmin would have to have a
button for it because a SET couldn't control it.
I know the server-side isn't optimal, but is the alternative worse?
Also, if Peter wants clients to be able to just issue a query and know
it commits, should we just disable setting autocommit in postgresql.conf
and per-user/db, and force applications to turn it on explicitly?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
