Re: [INTERFACES] Roadmap for FE/BE protocol redesign

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