looking at the patch, I realized the renametrig_partition could use an index leading with tgparentid, without the need to traverse the child tables. Since we still need to lock them, there is likely no practical performance gain. But I am surprised there is no unique index on (tgparentid, tgrelid), which sounds like a decent sanity check to have anyways.
From: Alvaro Herrera <alvherre@alvh.no-ip.org> Sent: Thursday, July 22, 2021 00:16 To: Arne Roland Cc: vignesh C; Zhihong Yu; Pg Hackers Subject: Re: Rename of triggers for partitioned tables
... now, thinking about how does pg_dump deal with this, I think this thread is all wrong, or at least mostly wrong. We cannot have triggers in partitions with different names from the triggers in the parents. pg_dump would only dump the trigger in the parent and totally ignore the ones in children if they have different names.
That makes things simpler. The reasoning behind the ONLY variant was not to break things that worked in the past. If it never worked in the past, there is no reason to offer backwards compatibility.
1. if we detect that we're running in a trigger which has tgparentid set, we have to raise an error, 2. if we are running on a trigger in a partitioned table, then ONLY must not be specified.
I think that would make the whole idea of allowing ONLY obsolete altogether anyways. I'd vote to simply scratch that syntax. I will work on updating your version 9 of this patch accordingly.
I think we should do something about pg_upgrade. The inconsistency is obviously broken. I'd like it to make sure every partitioned trigger is named correctly, simply taking the name of the parent. Simplifying the state our database can have, might help us to avoid future headaches.
