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 Mon, 29 Jan 2018 at 07:17 Bruce Momjian <br...@momjian.us> wrote:
> On Sun, Jan 28, 2018 at 06:12:01PM -0500, Tom Lane wrote:
> > Bruce Momjian <br...@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 <br...@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 +
>
