Re: Vote on SET in aborted transaction

Hiroshi Inoue wrote:
> 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 ?

Hiroshi, we need a psql solution too.  People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.

I now understand your point that from a ODBC perspective, you may not
want SETs rolled back and you would rather ODBC handle what to do with
SETs.  Not sure I like pushing that job off to the application
programmer, but I think I see your point.

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