Avoid failure when altering state of partitioned foreign-key triggers.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 4 Mar 2023 18:32:35 +0000 (13:32 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 4 Mar 2023 18:32:35 +0000 (13:32 -0500)
commit6949b921d545809a83f8a6bad4948f9012a76fb6
tree6646b139d5256411c11b570c8eeb70a8ee6329aa
parentf62975b2af6ace276a1d564a070b0aef479025af
Avoid failure when altering state of partitioned foreign-key triggers.

Beginning in v15, if you apply ALTER TABLE ENABLE/DISABLE TRIGGER to
a partitioned table, it also affects the partitions' cloned versions
of the affected trigger(s).  The initial implementation of this
located the clones by name, but that fails on foreign-key triggers
which have names incorporating their own OIDs.  We can fix that, and
also make the behavior more bulletproof in the face of user-initiated
trigger renames, by identifying the cloned triggers by tgparentid.

Following the lead of earlier commits in this area, I took care not
to break ABI in the v15 branch, even though I rather doubt there
are any external callers of EnableDisableTrigger.

While here, update the documentation, which was not touched when
the semantics were changed.

Per bug #17817 from Alan Hodgson.  Back-patch to v15; older versions
do not have this behavior.

Discussion: https://postgr.es/m/17817-31dfb7c2100d9f3d@postgresql.org
doc/src/sgml/ref/alter_table.sgml
src/backend/commands/tablecmds.c
src/backend/commands/trigger.c
src/include/commands/trigger.h
src/test/regress/expected/triggers.out
src/test/regress/sql/triggers.sql