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
> create schema foo;
> set search_path = foo;
> There is *no* alternative here but to roll back the search_path
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
In response to
pgsql-hackers by date
|Next:||From: Lincoln Yeoh||Date: 2002-04-24 07:12:46|
|Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE|
|Previous:||From: Philip Warner||Date: 2002-04-24 05:58:15|
|Subject: Re: Inefficient handling of LO-restore + Patch |