It turns out that more work is needed here to ensure we recurse to all
children on both sides, and so that all involved triggers are altered.
There is a case where it doesn't seem like we can easily give
non-surprising behavior: when multi-level partitioning is used, a
constraint is defined in the top level and then it is altered in the
middle level, then we don't have access to the action triggers, because
those are defined at the parent level. I opted for adding a WARNING
message in that case. Other options were 1) to raise an error if
altering a constraint that's not top level, but I fear that might break
restoring dumps of existing database; 2) reach up and alter the parent
constraint instead, but that seems too magical. This doesn't seem worth
spending too much sweat on, since it's a pretty fringe case anyway.
Patch for HEAD attached.
I also noticed that we're calling InvokeObjectPostAlterHook wrong in one
place: when altering the trigger properties, we call it with the
constraint OID instead of the trigger OID. I'll fix that in a separate
commit -- that was introduced by 578b229718e8 ("Remove WITH OIDS
support, change oid catalog column visibility.") in pg12. It's sad that
nobody ever noticed ... looks like the sepgsql stuff isn't getting much
testing.
--
Álvaro Herrera 39°49'30"S 73°17'W