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 3CC76090.E1E8E25E@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  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 Inouehttp://w2422.nsk.ne.jp/~inoue/


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Bruce Momjian
Date:
Subject: Re: Sequential Scan Read-Ahead