Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Vote totals for SET in aborted transaction |
Date | |
Msg-id | 200204252125.g3PLPlx20356@candle.pha.pa.us Whole thread Raw |
In response to | Re: Vote totals for SET in aborted transaction (Vince Vielhaber <vev@michvhf.com>) |
Responses |
Re: Vote totals for SET in aborted transaction
Re: Vote totals for SET in aborted transaction |
List | pgsql-hackers |
Marc is suggesting we may want to match Oracle somehow. I just want to have our SET work on a sane manner. --------------------------------------------------------------------------- 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, Pennsylvania19026
pgsql-hackers by date: