| From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Vote on SET in aborted transaction |
| Date: | 2002-04-25 00:06:59 |
| Message-ID: | 3CC748A3.22170450@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-04-25 00:39:28 | Vote totals for SET in aborted transaction |
| Previous Message | Hiroshi Inoue | 2002-04-24 23:42:43 | Re: Vote on SET in aborted transaction |