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

Re: Vote totals for SET in aborted transaction

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <janwieck(at)yahoo(dot)com>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>,Vince Vielhaber <vev(at)michvhf(dot)com>,Mike Mascari <mascarm(at)mascari(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-26 14:46:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > Marc is suggesting we may want to match Oracle somehow.
> > > >
> > > > I just want to have our SET work on a sane manner.
> > >
> > > Myself, I wonder why Oracle went the route they went ... does anyone have
> > > access to a Sybase / Informix system, to confirm how they do it?  Is
> > > Oracle the 'odd man out', or are we going to be that?  *Adding* something
> > > (ie. DROP TABLE rollbacks) that nobody appears to have is one thing ...
> > > but changing the behaviour is a totally different ...
> >
> > Yes, let's find out what the others do.  I don't see DROP TABLE
> > rollbacking as totally different.  How is it different from SET?
>     Man,  you  should know that our transactions are truly all or
>     nothing.  If you discard a transaction, the stamps  xmin  and
>     xmax are ignored.  This is a fundamental feature of Postgres,
>     and if you're half through a utility command when  you  ERROR
>     out,  it  guarantees consistency of the catalog.  And now you
>     want us to violate this concept for compatibility to Oracle's
>     misbehaviour? No, thanks!

So you do see a difference between SET and DROP TABLE because the second
is a utility command. OK, I'll buy that, but my point was different.

My point was that we don't match Oracle for DROP TABLE, so why is
matching for SET so important?

  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: Bruce MomjianDate: 2002-04-26 14:49:55
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Tom LaneDate: 2002-04-26 14:46:24
Subject: Re: pid gets overwritten in OSX

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