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

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(at)candle(dot)pha(dot)pa(dot)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(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