Re: Vote on SET in aborted transaction - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Vote on SET in aborted transaction
Date
Msg-id 3CC7567C.8383BC64@tpf.co.jp
Whole thread Raw
In response to Re: Vote on SET in aborted transaction  (Jan Wieck <janwieck@yahoo.com>)
Responses Re: Vote on SET in aborted transaction  (Jan Wieck <janwieck@yahoo.com>)
List pgsql-hackers
Jan Wieck wrote:
> 
> 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".

What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
schema1.t1 to foo.t1 in case the previous create schema
command suceeded.

regards, 
Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Vote on SET in aborted transaction
Next
From: Tom Lane
Date:
Subject: Re: Vote on SET in aborted transaction