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)
