]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 5 Apr 2023 16:56:30 +0000 (12:56 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 5 Apr 2023 16:56:30 +0000 (12:56 -0400)
commitb02bf1e46048ff4b8e9138fb0d5c1fa442fd7380
treec586655f47c1f642fcf66c9fdc0c137846b312ec
parentba8fd17be04a763d0249d64f56659183ce86b1f6
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.

In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned
on cloned triggers, failing to find the clones because it thought they
were system triggers.  Other variants of ENABLE/DISABLE TRIGGER would
improperly apply a superuserness check.  Fix by adjusting the is-it-
a-system-trigger check to match reality in those branches.  (As far
as I can find, this is the only place that got it wrong.)

There's no such bug in v15/HEAD, because we revised the catalog
representation of system triggers to be what this code was expecting.
However, add the test case to these branches anyway, because this area
is visibly pretty fragile.  Also remove an obsoleted comment.

The recent v15/HEAD commit 6949b921d fixed a nearby bug.  I now see
that my commit message for that was inaccurate: the behavior of
recursing to clone triggers is older than v15, but it didn't apply
to the case in v13/v14 because in those branches parent partitioned
tables have no pg_trigger entries for foreign-key triggers.  But add
the test case from that commit to v13/v14, just to show what is
happening there.

Per bug #17886 from DzmitryH.

Discussion: https://postgr.es/m/17886-5406d5d828aa4aa3@postgresql.org
src/backend/commands/trigger.c
src/test/regress/expected/triggers.out
src/test/regress/sql/triggers.sql