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

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
>