Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: Vote totals for SET in aborted transaction
Date
Msg-id 20020425225229.R2368-100000@mail1.hub.org
Whole thread Raw
In response to Re: Vote totals for SET in aborted transaction  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Vote totals for SET in aborted transaction  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Vote totals for SET in aborted transaction  (Lee Kindness <lkindness@csl.co.uk>)
List pgsql-hackers
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 ...

> ---------------------------------------------------------------------------
>
> Vince Vielhaber wrote:
> > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > > > My guess is that we should implement #1 and see what feedback we get in
> > > > > 7.3.
> > > >
> > > > IMHO, it hasn't been thought out well enough to be implemented yet ... the
> > > > options have been, but which to implement haven't ... right now, #1 is
> > > > proposing to implement something that goes against what *at least* one of
> > > > DBMS does ... so now you have programmers coming from that environment
> > > > expecting one thing to happen, when a totally different thing results ...
> > >
> > > But, they don't expect our current behavior either (which is really
> > > weird).  At least I haven't seen anyone complaining about our current
> > > weird behavior, and we are improving it, at least as our users request
> > > it.
> > >
> > > In fact, Oracle doesn't implement rollback for DROP TABLE, and we
> > > clearly wanted that feature, so do we ignore rollback for SET too?
> > >
> > > I guess I don't see it as a killer if we can do better than Oracle, or
> > > at least most of our users (including you) think it is better than
> > > Oracle.  If someone wants Oracle behavior after we do #1, we can add it,
> > > right?
> >
> > I've often wondered why the "but that's how the other RDBMS is doing
> > it" is only used when convenient.  Case in point is the issue (that's
> > been resolved) with the insert into foo(foo.bar) ...  where every one
> > I checked accepted it, but that wasn't a good enough reason for us to
> > support it.  Until the fact that applications that were using that
> > syntax was causing PostgreSQL not to be used was the issue resolved.
> > Now I'm seeing the "but that's the way Oracle does it" excuse being
> > used to justify a change.  Can we try for some consistancy?
> >
> > Vince.
> > --
> > ==========================================================================
> > Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
> >          56K Nationwide Dialup from $16.00/mo at Pop4 Networking
> >         Online Campground Directory    http://www.camping-usa.com
> >        Online Giftshop Superstore    http://www.cloudninegifts.com
> > ==========================================================================
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> --
>   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, Pennsylvania 19026
>



pgsql-hackers by date:

Previous
From: Kyle
Date:
Subject: Re: Sequential Scan Read-Ahead
Next
From: Bruce Momjian
Date:
Subject: Re: Sequential Scan Read-Ahead