Hiroshi Inoue wrote:
> Tom Lane wrote:
> >
>
> > Right offhand, I am not seeing anything here for which there's a
> > compelling case not to roll it back on error.
> >
> > In fact, I have yet to hear *any* plausible example of a variable
> > that we would really seriously want not to roll back on error.
>
> Honetsly I don't understand what kind of example you
> expect. How about the following ?
>
> [The curren schema is schema1]
>
> begin;
> create schema foo;
> set search_path = foo;
> create table t1 (....);
> .
> [error occurs]
> rollback;
> insert into t1 select * from schema1.t1;
>
> Should the search_path be put back in this case ?
> As I mentioned already many times, it doesn't seem
> *should be* kind of thing.
Sure should it! You gave an example for the need to roll back, because otherwise you would end up with an
invalid search path "foo".
I still believe that rolling back is the only right thing to do. What if your application doesn't even know
that some changes happened? Have a trigger that set's seqscan off, does some stuff and intends to reset it later
again.Now it elog's out before, so your application will have to live with this mis-setting on this pooled DB
connectionuntil the end? I don't think so!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
