Tom Lane writes:
"Michael Paesold" <[EMAIL PROTECTED]> writes:
Will this trigger still be called, so it can abort the delete?
We'd certainly still call triggers and check row-level constraints,
and any error would abort the whole statement (leaving A unmodified).
The case that I think we'd forbid if the implementation could support
doing so is where a BEFORE trigger cancels the B-update operation by
returning NULL. This currently leaves you with a row in B that violates
the FK constraint (once the A row is gone).
Triggers that modify the row to be stored are not a problem, because
B will have an AFTER trigger that rechecks the row against A anyway.
AFAICS it's only the silent-cancellation case that subverts RI
constraints.
Rules on B that rewrite the DELETE or UPDATE into something else are
also problematic.
This is all moot at the moment since Stephan pointed out that we still
need planning for the FK actions (ie the cascaded deletes/updates).
So I'm not currently thinking of redoing the implementation of actions.
Ok, thank you for the explanation. At least I am not worried about a future
reimplementation of the RI triggers.
Best Regards,
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
