Re: [JDBC] problem with new autocommit config parameter and

Tom Lane wrote:
> An example of how this would simplify life: consider the problem of
> a client that wants to ensure autocommit is on. A simple
> SET autocommit TO on;
> doesn't work at the moment: if autocommit is off, then you'll need
> to issue a COMMIT as well to get out of the implicitly started
> transaction. But you don't want to just issue a COMMIT, because
> you'll get a nasty ugly WARNING message on stderr if indeed autocommit
> was on already. The only warning-free way to issue a SET right now
> if you are uncertain about autocommit status is
> BEGIN; SET .... ; COMMIT;
> Blech. But if SET doesn't start a transaction then you can still
> just do SET. This avoids some changes we'll otherwise have to make
> in libpq startup, among other places.
>
> Does anyone see any cases where it's important for SET to start
> a transaction? (Of course, if you are already *in* a transaction,
> the SET will be part of that transaction. The question is whether
> we want SET to trigger an implicit BEGIN or not.)

Uh, well, because we now have SET's rollback in an aborted transaction,
there is an issue of whether the SET is part of the transaction or not.
Seems it has to be for consistency with our rollback behavior.

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