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 01:59:15
Message-ID: 200204250159.g3P1xFn06013@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(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 Jan Wieck 2002-04-25 02:00:41 Re: Vote totals for SET in aborted transaction
Previous Message Bruce Momjian 2002-04-25 01:56:41 Re: Sequential Scan Read-Ahead