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: