Re: Revisited: Transactions, insert unique.
От | Joachim Achtzehnter |
---|---|
Тема | Re: Revisited: Transactions, insert unique. |
Дата | |
Msg-id | Pine.LNX.4.21.0004252059001.446-100000@wizard.kraut.bc.ca обсуждение исходный текст |
Ответ на | Re: Revisited: Transactions, insert unique. ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>) |
Список | pgsql-general |
Today, in a message to pgsql-general, Ross J. Reedstrom wrote: > > On Mon, Apr 24, 2000 at 09:23:48PM -0700, Joachim Achtzehnter wrote: > > > > I suspect, though, that to support statement-level aborts > > more is needed than an overhaul of the error system. Statement > > level aborts are essentially a form of nested transaction,... > > Hmm, sounds like your moving the goal posts: now you want checkpoints, > no? I didn't say that. Was merely pointing out that supporting statement level aborts may be more difficult than it seems. This is not just an error reporting issue. What it amounts to is a special case of nested transactions, i.e. where every statement is an implicit nested transaction. Keep in mind that a statement can be very complex, and it can update, directly or indirectly via triggers, many rows in many tables. To precisely undo the effect of such a statement may not be trivial, in general. [quote from Gray and Reuter omitted] > Doesn't this quote mearly bemoan the fact that nesting of transactions > is _not_ a general requirement of "even today's SQL systems"? I can't > follow the example, The quote essentially said this: Most existing SQL systems don't support user-controlled nested transactions. The authors find this surprising because these same systems DO support a special form of nested transactions, namely statement-level abort. What they are complaining about is the fact that vendors choose ad hoc approaches to implement the special case, instead of implementing the general case. The general mechanism could then be used to achieve statement-level aborts as well as supporting user-controlled nested transactions. Joachim -- private: joachim@kraut.bc.ca (http://www.kraut.bc.ca) work: joachim@mercury.bc.ca (http://www.mercury.bc.ca)
В списке pgsql-general по дате отправления: