Skip site navigation (1) Skip section navigation (2)

Re: Vote on SET in aborted transaction

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-04-23 17:29:20
Subject: Re: new food for the contrib/ directory
Previous:From: Jan WieckDate: 2002-04-23 16:59:58
Subject: Re: Vote on SET in aborted transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group