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 connection until 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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
