On Thu, 2007-08-02 at 12:24 -0800, Stephan Szabo wrote: > On Thu, 8 Feb 2007, Marc Munro wrote: > > > I don't think this does stop the second from continuing before the > > first. What will stop it, is the eventual lock that is taken on the > > child (triggering) record. > > But at that point, you've already had to compose the new row in order to > call the trigger for the ri check, right? So, one of those new rows will > be out of date by the time it actually gets the lock. Presumably that > means that you need to recalculate the new row, but you've already done a > check and gotten a lock based on the old new row.
Yes. That is tricky. For my proposed scheme to work, I guess we'd have to be able to drop those locks which were just acquired by the RI triggers. Not too simple, I guess. > Also, another big problem is the fact that SQL requires that the action > already have happened before the check in cases where the constraint > references the same table. The row being updated or inserted might > reference a row that will be updated or inserted by a later action of the > same statement. Hmmm. That does seem to be the final nail in the coffin. Consider the proposal withdrawn, and thanks for explaining it all to me. __ Marc
signature.asc
Description: This is a digitally signed message part
