Florian Pflug <f...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
