Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
