Re: [INTERFACES] Roadmap for FE/BE protocol redesign - Mailing list pgsql-hackers

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,
Pennsylvania19073