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.


Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to