Re: Vote totals for SET in aborted transaction
От | Jan Wieck |
---|---|
Тема | Re: Vote totals for SET in aborted transaction |
Дата | |
Msg-id | 200204261316.g3QDGVe08779@saturn.janwieck.net обсуждение исходный текст |
Ответ на | Re: Vote totals for SET in aborted transaction (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Vote totals for SET in aborted transaction
Re: Vote totals for SET in aborted transaction |
Список | pgsql-hackers |
Bruce Momjian wrote: > Marc G. Fournier wrote: > > 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 ... > > 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? Man, you should know that our transactions are truly all or nothing. If you discard a transaction, the stamps xmin and xmax are ignored. This is a fundamental feature of Postgres, and if you're half through a utility command when you ERROR out, it guarantees consistency of the catalog. And now you want us to violate this concept for compatibilityto Oracle's misbehaviour? No, thanks! Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: