aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2023-03-04 13:32:35 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2023-03-04 13:32:35 -0500
commitf61e60102f08305f3cb9e55a7958b8036a02fe39 (patch)
treec2c039a0f98a6ee77493e583e151dd21b67a1e31 /src/backend/executor/nodeModifyTable.c
parent9d41ecfcd9a7cb4ec6b20add4a55603ebba03f0d (diff)
downloadpostgresql-f61e60102f08305f3cb9e55a7958b8036a02fe39.tar.gz
postgresql-f61e60102f08305f3cb9e55a7958b8036a02fe39.zip
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
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions