From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
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 04:43:48 |
Message-ID: | 200204260443.g3Q4hm821818@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marc G. Fournier wrote:
> > 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 ...
Yes, I understand, and the logical place would be GUC. However, if we
add every option someone would ever want to GUC, the number of options
would be huge.
We currently have a problem doing #2. My suggestion is that we go to #1
and wait to see if anyone actually asks for the option of choosing #3.
--
Bruce Momjian | http://candle.pha.pa.us
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
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2002-04-26 05:09:23 | Re: Block size: 8K or 16K? |
Previous Message | Lincoln Yeoh | 2002-04-26 03:48:49 | Re: Vote totals for SET in aborted transaction |