Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Can we all compromise on that?
> No.
Oh dear...
> I agree that there may be some variables that must be rolled back, or
> where automatic reset on transaction end may be desirable (note that these
> are two different things), but for some variables it's completely
> nonsensical. Those variables describe session characteristics, not
> database state. For instance, time zone, default_transaction_isolation.
Uh, why? I do not see why it's unreasonable for
BEGIN;
SET time_zone = whatever;
ROLLBACK;
to be a no-op. The fact that we haven't done that historically doesn't
count for much (unless your argument is "backwards compatibility" ...
but you didn't say that). Not long ago we couldn't roll back a DROP
TABLE command; but that didn't make it right.
> Or consider you're raising the debug level, but it gets reset during
> commit so you can't debug the commit process.
It wouldn't get reset during commit, so I assume you really meant you
wanted to debug an abort problem. But even there, what's the problem?
Set the variable *before* you enter the transaction that will abort.
> Or in the future we may
> have some SQL-compatible always-in-transaction mode which would mean that
> you could never set any variable to last.
Only if this mode prevents you from ever committing anything. Somehow
I doubt that that's either SQL-compatible or useful.
> If you want something that's transaction-specific, invent a new mechanism.
I didn't say "transaction specific". I said that if you do a SET inside
a transaction block, and then the transaction is aborted, the effects of
the SET ought to roll back along with everything else you did inside
that transaction block. I'm not seeing what the argument is against
this.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
