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]
> create schema foo;
> set search_path = foo;
> create table t1 (....);
> [error occurs]
> 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!
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
In response to
pgsql-hackers by date
|Next:||From: Hiroshi Inoue||Date: 2002-04-25 01:06:04|
|Subject: Re: Vote on SET in aborted transaction|
|Previous:||From: Bruce Momjian||Date: 2002-04-25 00:39:28|
|Subject: Vote totals for SET in aborted transaction|