From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vote on SET in aborted transaction |
Date: | 2002-04-23 17:09:59 |
Message-ID: | 6244.1019581799@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-23 17:29:20 | Re: new food for the contrib/ directory |
Previous Message | Jan Wieck | 2002-04-23 16:59:58 | Re: Vote on SET in aborted transaction |