Florian Pflug <fgp@phlo.org> wrote:
> Another option would be to re-issue the DELETE from the BEFORE
> DELETE trigger, and then return NULL. It'll cause the BEFORE
> DELETE trigger to be invoked recursively, but presumably the
> second invocation could easily detect that all required pre-delete
> actions have already taken place and exit early (and return OLD).
> In pseudo-code, something like
>
> BEFORE DELETE ON <parent table>:
> DELETE FROM <child table> WHERE parent_id = OLD.id;
> IF FOUND THEN
> -- Removing children might have modified our row,
> -- so returning non-NULL is not an option
> DELETE FROM <table> WHERE id = OLD.id;
> RETURN NULL;
> ELSE
> -- No children removed, so our row should be unmodified
> RETURN OLD;
> END IF;
Yeah, that would cover it all right. That pretty much eliminates my
objections to your "check for error after firing each BEFORE
trigger" approach.
-Kevin