Re: Vote on SET in aborted transaction

Tom Lane wrote:
>
> 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.

Hmm I don't understand which to vote, sorry.
Are they all exclusive in the first place ?

> 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.

begin;
xxxx;
ERROR: parser: parse error at or near "xxxx"

There's *no* alternative here but to call *rollback*(commit).
However PostgreSQL doesn't call *rollback* automatically and
it's the user's responsibility to call *rollback* on errors.
IMHO what to do with errors is users' responsibility basically.
The behavior of the *search_path" variable is a *had better*
or *convenient* kind of thing not a *no alternative* kind
of thing.

regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/