Triggers & Mutating Tables

From: Dimitri Tombroff <dimi_at_nikita.inria.fr>
Date: 14 Oct 1994 17:16:06 GMT
Message-ID: <37mecm$cdl_at_news-rocq.inria.fr>


The rationale of mutating tables seems very mysterious to me.

In the manual they say it is needed so that a trigger sees a consistent state !? I do not see why a trigger accessing the updates of the triggering transaction would see something inconsistent, since it becomes part of this transaction.
Clearly, having such a restriction on triggers simplify their semantics and executions which are known to be complex, but at which price !?

Also that thing about conflicts (manual page 8-9, top of the page). Why can't a trigger take locks like everybody (I mean locks under the transaction identifier of the triggering transaction) ? I can't see any good reason justifying the rollback to savepoint technique when a conflict is detected. Am I missing something here ?.   

Any guess about real reasons for such choices ? Was it so complicated to deal with locks in their implementation ?

(Hope this topic was not recently discussed, I just joined this newsgroup)

Dimitri Tombroff
INRIA/RODIN Received on Fri Oct 14 1994 - 18:16:06 CET

Original text of this message