Re: Vote on SET in aborted transaction

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Michael Loftis <mloftis(at)wgops(dot)com>, Jan Wieck <janwieck(at)yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote on SET in aborted transaction
Date: 2002-04-25 03:03:08
Message-ID: 200204250303.g3P338o13330@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > >
> > > What are you expecting for psql e.g. the following
> > > wrong(?) example ?
> > >
> > > [The curren schema is schema1]
> > > begin;
> > > create schema foo;
> > > set search_path = foo;
> > > create table t1 (....); [error occurs]
> > > commit;
> > > insert into t1 select * from schema1.t1;
> >
> > I am expecting the INSERT will use the search_path value that existed
> > before the error transaction began.
> >
>
> So you see foo.t1 which is a copy of schema1.t1
> if all were successful and you may be able to see
> the doubled schema1.t1 in case of errors.

Yes, I think that is how it would behave. If you don't roll back 'set
search_path', you are pointing to a non-existant schema.

Probably the proper thing here would be to have the INSERT in the
transaction too.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2002-04-25 03:11:51 Re: Vote on SET in aborted transaction
Previous Message Hiroshi Inoue 2002-04-25 03:00:28 Re: Vote on SET in aborted transaction