Re: Rename of triggers for partitioned tables
Arne Roland <a.roland@index.de>
From: Arne Roland <A.Roland@index.de>
To: David Steele <david@pgmasters.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-29T07:37:53Z
Lists: pgsql-hackers
David Steele wrote: > Arne, thoughts on Álvaro's comments? > > Marking this patch as Waiting for Author. Thank you for the reminder. I was to absorbed by other tasks. I should be more present in the upcoming weeks. > I think you did not register the patch in commitfest, so I did that for > you: https://commitfest.postgresql.org/32/2943/ Thank you! I should have done that. > As you say, triggers on children don't necessarily have to have the same > name as on parent; this already happens when the trigger is renamed in > the child table but not on parent. In that situation the search on the > child will fail, which will cause the whole thing to fail I think. > > We now have the column pg_trigger.tgparentid, and I think it would be > better (more reliable) to search for the trigger in the child by the > tgparentid column instead, rather than by name. The last patch already checks tgparentid and errors out if either of those do not match. The reasoning behind that was, that I don't see a clear reasonable way to handle this scenario. If the user choose to rename the child trigger, I am at a loss what to do. I thought to pass it back to the user to solve the situation instead of simply ignoring the users earlier rename. Silently renaming sounded a bit presumptuous to me, even though I don't care that much either way. Do you think silently renaming is better than yielding an error? > Also, I think it would be good to have > ALTER TRIGGER .. ON ONLY parent RENAME TO .. > to avoid recursing to children. This seems mostly pointless, but since > we've allowed changing the name of the trigger in children thus far, > then we've implicitly made it supported to have triggers that are named > differently. (And it's not entirely academic, since the trigger name > determines firing order.) If it would be entirely academic, I wouldn't have noticed the whole thing in the first place. The on only variant sounds like a good idea to me. Even though hardly worth any efford, it seems simple enough. I will work on that. > Alternatively to this last point, we could decide to disallow renaming > of triggers on children (i.e. if trigger has tgparentid set, then > renaming is disallowed). I don't have a problem with that, but it would > have to be an explicit decision to take. I rejected that idea, because I was unsure what to do with migrations. If we would be discussing this a few years back, this would have been likely my vote, but I don't see it happening now. Regards Arne
Commits
-
Remove newly added useless assertion check
- 21b3aa9c8faf 15.0 landed
-
Make ALTER TRIGGER RENAME consistent for partitioned tables
- 80ba4bb38353 15.0 landed
-
Fix pg_dump for disabled triggers on partitioned tables
- ccfc3cbb341a 11.13 cited
-
Preserve firing-on state when cloning row triggers to partitions
- fed35bd4a650 11.13 cited
-
Fix ALTER TABLE .. ENABLE/DISABLE TRIGGER recursion
- bbb927b4db9b 14.0 cited
-
Record parents of triggers
- b9b408c48724 13.0 cited
-
Allow FOR EACH ROW triggers on partitioned tables
- 86f575948c77 11.0 cited