Re: Vote on SET in aborted transaction

Hiroshi Inoue wrote:
> > 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.

I understand from an ODBC perspective that it is the apps
responsibility, but we need some defined behavior for a psql script that
is fed into the database.

Assuming the SET commands continue to come after it is aborted but
before the COMMIT/ROLLBACK, we need to define how to handle it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026