"Michael Paesold" <[EMAIL PROTECTED]> writes:
> B (id) references A (id), with ON DELETE CASCADE
> Usually deleting a row from A will cause all referencing rows in B to be
> deleted, too. Nevertheless B has a BEFORE DELETE trigger "check_delete" that
> checks if a row of B may be deleted or not. I.e. it contains a IF ... RAISE
> EXCEPTION...
> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
