Re: Vote on SET in aborted transaction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Vote on SET in aborted transaction
Date
Msg-id 6244.1019581799@sss.pgh.pa.us
Whole thread Raw
In response to Vote on SET in aborted transaction  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>     1 - All SETs are rolled back in aborted transaction
>     2 - SETs are ignored after transaction abort
>     3 - All SETs are honored in aborted transaction
>     ? - Have SETs vary in behavior depending on variable

My vote is 1 - roll back all SETs.

I'd be willing to consider making the behavior variable-specific
if anyone can identify particular variables that need to behave
differently.  But overall I think it's better that the behavior
be consistent --- so you'll need a good argument to convince me
that anything should behave differently ;-).

There is a variant case that should also have been illustrated:
what if there is no error, but the user does ROLLBACK instead of
COMMIT?  The particular case that is causing difficulty for me is
begin;create schema foo;set search_path = foo;rollback;

There is *no* alternative here but to roll back the search_path
setting.  Therefore, the only alternatives that actually count
are 1 and ? --- if you don't like 1 then you are voting for
variable-specific behavior, because search_path is going to behave
this way whether you like it or not.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Vote on SET in aborted transaction
Next
From: Bruce Momjian
Date:
Subject: Re: new food for the contrib/ directory