Re: SQL BEFORE puzzle

This was the reason given in,

Cochrane, R., Pirahesh, H. and Mattos, N. M. Integrating Triggers and Declarative Constraints in SQL Database Sytems. In: Proceedings of the 22nd VLDB Conference. Mumbai, India. Morgan Kaufmann, 1996.

which I believe heavily influenced the SQL Standard on triggers.

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:vaBkk.17847$89.1733_at_nlpi069.nbdc.sbc.com... ....
>
> I would think that the restriction is supposed to prevent something like:
>
> update T ....
> beforeT: update T ....
> beforeT: update T ....
> beforeT: update T ....
> ...and so on....
> ...and so on....
> ...and so on....
>
> where the pending updates would pile up. Note that:
>
> update T ....
> afterT: update T ....
> afterT: update T ....
> afterT: update T ....
> ...and so on....
> ...and so on....
> ...and so on....
>
> wouldn't cause the updates to pile up (even though the transaction
> controlling them would remain outstanding) because instead of being held
> waiting to be applied to the table as in the case of before triggers, they
> would have already been applied before each subsequent afterT is executed,
> making the recursive afterT more like just an iteration of updates within
> a transaction.
Received on Mon Aug 11 2008 - 12:29:38 CEST