Re: Vote on SET in aborted transaction

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: Vote on SET in aborted transaction
Дата
Msg-id 3CC7567C.8383BC64@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Vote on SET in aborted transaction  (Jan Wieck <janwieck@yahoo.com>)
Ответы Re: Vote on SET in aborted transaction  (Jan Wieck <janwieck@yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: Vote on SET in aborted transaction
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Vote on SET in aborted transaction