Re: pg_trigger.tgparentid

On 2020-Feb-19, Amit Langote wrote:

> Or:
> 
>          * However, if our parent is a partition itself, there might be
>          * internal triggers that must not be skipped.  For example, triggers
>          * on the parent that were in turn cloned from its own parent are
>          * marked internal, which must be cloned to the partition.

Thanks for pointing this out -- I agree it needed rewording.  I slightly
adjusted your text like this:

		 * Internal triggers require careful examination.  Ideally, we don't
		 * clone them.  However, if our parent is itself a partition, there
		 * might be internal triggers that must not be skipped; for example,
		 * triggers on our parent that are in turn clones from its parent (our
		 * grandparent) are marked internal, yet they are to be cloned.

Is this okay for you?

Tom Lane wrote:

> It'd be nice if the term "parent trigger" were defined somewhere in
> this.  Seems all right otherwise.

Fair point.  I propose to patch catalog.sgml like this

      <entry>
       Parent trigger that this trigger is cloned from, zero if not a clone;
       this happens when partitions are created or attached to a partitioned
       table.
      </entry>

It's perhaps not great to have to explain the parentage concept in the
catalog docs, so I'm going to go over the other documentation pages
(trigger.sgml and ref/create_trigger.sgml) to see whether they need any
patching; it's possible that we neglected to update them properly when
the partitioning-related commits went it.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services