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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073