From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Michael Loftis <mloftis(at)wgops(dot)com> |
Cc: | 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>, 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 01:49:04 |
Message-ID: | 3CC76090.E1E8E25E@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Loftis wrote:
>
> Hiroshi Inoue wrote:
>
> >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.
> >
> Exactly, in this example shows exactly why SETs should be part of the
> transaction and roll back. Heck the insert may not even fail after all
> anyway and insert into the wrong schema. If the insert depends on the
> schema create succeeding it should be in the same transaction. (IE it
> would get rolled back or not happen at all)
Where's the restriction that all objects in a schema
must be created in an transaction ? Each user has his
reason and would need various kind of command call sequence.
What I've mainly insisted is what to do with errors is
users' responsibilty but I've never seen the agreement
for it. So my current understanding is you all
are thinking what to do with errors is system's
responsibilty. Then no matter how users call commands
the dbms must behave appropriately, mustn't it ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-25 01:56:41 | Re: Sequential Scan Read-Ahead |
Previous Message | Bruce Momjian | 2002-04-25 01:46:58 | Re: Vote totals for SET in aborted transaction |