Re: Vote totals for SET in aborted transaction

From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: 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 03:31:18
Message-ID: 20020426002739.B2368-100000@mail1.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 25 Apr 2002, 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?

SET currently has an "accepted behaviour" with other DBMSs, or, at least,
with Oracle, and that is to ignore the rollback ...

DROP TABLE also had an "accepted behaviour", and that was to leave it
DROPed, so "oops, I screwed up and just lost a complete table as a
result", which, IMHO, isn't particularly good ...

NOTE that I *do* think that #1 is what *should* happen, but there should
be some way of turning off that behaviour so that we don't screw up ppl
expecting "Oracles behaviour" ... I just think that implementing #1
without the 'switch' is implementing a half-measure that is gonna come
back and bite us ...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lincoln Yeoh 2002-04-26 03:48:49 Re: Vote totals for SET in aborted transaction
Previous Message Curt Sampson 2002-04-26 02:51:43 Re: Index Scans become Seq Scans after VACUUM ANALYSE