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

Tom Lane wrote:
> Bruce Momjian  writes:
> > Tom Lane wrote:
> >> 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.
> 
> Yeah, it must be part of the transaction unless we want to reopen the
> SET-rollback can of worms (which I surely don't want to).
> 
> However, a SET issued outside any pre-existing transaction block could
> form a self-contained transaction without any logical difficulty, even
> in autocommit-off mode.  The question is whether that's more or less
> convenient, or standards-conforming, than what we have.

That seems messy.  What you are saying is that if autocommit is off,
then in:

	SET x=1;
	UPDATE ...
	SET y=2;
	ROLLBACK;

that the x=1 doesn't get rolled back bu the y=2 does?  I can't see any
good logic for that.

> An alternative that I'd really rather not consider is making SET's
> behavior dependent on exactly which variable is being set ...

Agreed.  We discussed that in the SET rollback case and found it was
more trouble that it was worth.

-- 
  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, Pennsylvania 19073