From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Barry Lind <blind@xythos.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Alvaro Herrera <alvherre@dcc.uchile.cl>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
Date: Fri, 21 Mar 2003 17:36:03 -0500 (EST)
Message-ID: <200303212236.h2LMa3118950@candle.pha.pa.us> (raw)
In-Reply-To: <3E7B84ED.5080808@xythos.com>
Man, I lost another vote! :-)
---------------------------------------------------------------------------
Barry Lind wrote:
> In general I agree with Tom. GUC is the wrong mechanism for autocommit.
> The reason being that it isn't a system administrators decision what
> value autocommit should have. It is generally dictated by the client
> protocol or application.
>
> Now that being said, it is nice for the client to be able to simply tell
> the server "you are in autocommit mode until I tell you otherwise".
> Instead of having to worry about trapping each commit and rollback
> request to make sure you insert to proper begin.
>
> The current GUC autocommit is nice in that it makes it easier for the
> cleint to simply turn on or off the state. It is a problem because it
> is a GUC parameter and therefore can be changed by the admin (thus you
> don't know what your initial state is without asking the server) or the
> user (via sql SET, thus you don't know that it has changed).
>
> As I said in my earlier mail note from a jdbc perspective I can get it
> to work which ever way is decided (in fact the jdbc driver will probably
> need to support all of the ways, depending on if it is talking to a 7.2,
> 7.3 or 7.4 backend).
>
> My preference (given that I am detecting a willingness to make more
> significant changes in this area that I was expecting) would be to drop
> the GUC autocommit parameter. Replacing that functionality with the
> ability to set and discover the autocommit state via the FE/BE protocol.
>
> thanks,
> --Barry
>
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >
> >>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.
> >
> >
> > Peter's point, AIUI, is that that is a good thing.
> >
> > The problem with SET for autocommit is that every client program has to
> > *know*, without question, which setting it is using. Autocommit is just
> > about as dangerous as a GUC variable that, say, silently swaps the
> > meanings of INSERT and DELETE --- if you don't know which setting you
> > are using then you will get the wrong results.
> >
> > Thus it is not "convenient" to allow autocommit to be set in all the
> > weird and wonderful ways that we allow GUC variables to be set; it's
> > more like handing a razor blade to a baby. We've already found out that
> > all client-side apps have to explicitly force autocommit to the setting
> > they want, or they break. How is that a good thing?
> >
> > I think we *should* go back to the assumption that libpq-based programs
> > see autocommit-on behavior unless they take specific action to prevent
> > it. And that means that the client program has to take action to select
> > autocommit off, not that the admin can flick a switch remotely that will
> > affect clients.
> >
> > The real point is that both the client application and the client
> > library need to know what the autocommit behavior is. This is why
> > adding autocommit to the library APIs is the right thing, not the wrong
> > thing. When there are ways other than a library API call to set the
> > autocommit behavior, then one party or the other is out of the loop
> > about what the current behavior is, and that gets us right back into the
> > same mess.
> >
> > Basically I think that Peter is arguing that autocommit as a GUC
> > variable is a wrong and dangerous idea. And I'm forced to agree.
> > I was wrong to put it in, and I'm now willing to take it out again.
> > At the time it seemed like a reasonable shortcut around changing the
> > protocol --- but now that we're changing the protocol anyway, it's
> > better to get rid of the shortcut.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
>
>
>
--
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, Pennsylvania 19073
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: pgman@candle.pha.pa.us, blind@xythos.com, tgl@sss.pgh.pa.us, peter_e@gmx.net, alvherre@dcc.uchile.cl, pgsql-hackers@postgresql.org
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
In-Reply-To: <200303212236.h2LMa3118950@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox