Re: Vote totals for SET in aborted transaction
От | Bruce Momjian |
---|---|
Тема | Re: Vote totals for SET in aborted transaction |
Дата | |
Msg-id | 200204260443.g3Q4hm821818@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Vote totals for SET in aborted transaction ("Marc G. Fournier" <scrappy@hub.org>) |
Список | 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@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 по дате отправления: