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
