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

Re: Vote on SET in aborted transaction

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote on SET in aborted transaction
Date: 2002-04-24 06:13:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

	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.

Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Lincoln YeohDate: 2002-04-24 07:12:46
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous:From: Philip WarnerDate: 2002-04-24 05:58:15
Subject: Re: Inefficient handling of LO-restore + Patch

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