Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

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                        |
  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


pgsql-hackers by date

Next:From: Jan WieckDate: 2002-04-25 02:00:41
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Bruce MomjianDate: 2002-04-25 01:56:41
Subject: Re: Sequential Scan Read-Ahead

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group