The original confusion on this is answered in part by the following statement (taken from the answer to my SO question):
"UPDATEs and DELETEs on the parent table will affect rows in the child tables (if you don't specify ONLY), but triggers will only be fired by data modifications directed directly against the table with the trigger on it "
This clearly explains that a trigger attached to a parent table will not fire if the data being modified is in a child table.
The second part of the confusion is that INSERT is not considered to be a row modification and will fire a BEFORE INSERT trigger on the parent table even when the data goes into a child (whereas UPDATE and DELETE will not fire a parent trigger).
My proposal (adapted from Tom's):
In contrast, row-level UPDATE and DELETE triggers are fired for individual row change
events only on the table to which the trigger is attached. Therefore, UPDATE and DELETE triggers on
a parent table will only fire when rows in the parent table are being modified. Likewise,
UPDATE and DELETE triggers on a child table will only fire when rows in the child table are being modified.
Note that INSERT statements do not follow these update rules, so statements run on parent tables will
insert rows in child tables if the trigger function so directs.
The last line may need a bit of work, but I feel the text above it is clear.
Ian
On Sun, Jan 28, 2018 at 06:12:01PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Oh, I am sorry. I was focused on the first part of the sentence and
> > didn't notice your change to the second part. How is this attachment?
>
> Seems same as your previous version?
OK, new vesion that uses "explicitly named" in both modified doc lines.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
