Thread: pgsql: Create foreign key triggers in partitioned tables too

Create foreign key triggers in partitioned tables too

While user-defined triggers defined on a partitioned table have
a catalog definition for both it and its partitions, internal
triggers used by foreign keys defined on partitioned tables only
have a catalog definition for its partitions.  This commit fixes
that so that partitioned tables get the foreign key triggers too,
just like user-defined triggers.  Moreover, like user-defined
triggers, partitions' internal triggers will now also have their
tgparentid set appropriately.  This is to allow subsequent commit(s)
to make the foreign key related events to be fired in some cases
using the parent table triggers instead of those of partitions'.

This also changes what tgisinternal means in some cases.  Currently,
it means either that the trigger is an internal implementation object
of a foreign key constraint, or a "child" trigger on a partition
cloned from the trigger on the parent.  This commit changes it to
only mean the former to avoid confusion.  As for the latter, it can
be told by tgparentid being nonzero, which is now true both for user-
defined and foreign key's internal triggers.

Author: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Reviewed-by: Arne Roland <A.Roland@index.de>
Discussion: https://postgr.es/m/CA+HiwqG7LQSK+n8Bki8tWv7piHD=PnZro2y6ysU2-28JS6cfgQ@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/f4566345cf40b068368cb5617e61318da60676ec

Modified Files
--------------
src/backend/commands/tablecmds.c       | 413 +++++++++++++++++++++++++++------
src/backend/commands/trigger.c         | 101 +++++++-
src/bin/pg_dump/pg_dump.c              |  46 +++-
src/bin/pg_dump/pg_dump.h              |   2 +-
src/bin/psql/describe.c                |  10 +-
src/include/commands/trigger.h         |   4 +
src/test/regress/expected/triggers.out |   4 +-
7 files changed, 490 insertions(+), 90 deletions(-)

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> This also changes what tgisinternal means in some cases.  Currently,
> it means either that the trigger is an internal implementation object
> of a foreign key constraint, or a "child" trigger on a partition
> cloned from the trigger on the parent.  This commit changes it to
> only mean the former to avoid confusion.

Hmm, perhaps the column's description in catalogs.sgml deserves
an update?

            regards, tom lane

On Thu, Jan 6, 2022 at 7:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > This also changes what tgisinternal means in some cases.  Currently,
> > it means either that the trigger is an internal implementation object
> > of a foreign key constraint, or a "child" trigger on a partition
> > cloned from the trigger on the parent.  This commit changes it to
> > only mean the former to avoid confusion.
>
> Hmm, perhaps the column's description in catalogs.sgml deserves
> an update?

tginternal's description in catalogs.sgml is this:

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>tgisinternal</structfield> <type>bool</type>
      </para>
      <para>
       True if trigger is internally generated (usually, to enforce
       the constraint identified by <structfield>tgconstraint</structfield>)
      </para></entry>
     </row>

which matches what the commit restores tgisinternal's meaning to.  I
guess we forgot in 86f575948c77 to update this to mention
tgisinternal's relation to partitioning?

-- 
Amit Langote
EDB: http://www.enterprisedb.com