On 2020-Apr-18, Justin Pryzby wrote: > I haven't heard a compelling argument for or against either way. > > Maybe the worst behavior might be if, during ATTACH, we searched for a > matching > trigger, and "merged" it (marked it inherited) if it matched. That could be > bad if someone *wanted* two triggers, which seems unlikely, but to each their > own.
I think the simplicity argument trumps the other ones, so I agree to go with your v3 patch proposed downthread. What happens if you detach the parent? I mean, should the trigger removal recurse to children? > It occured to me that we don't currently distinguish between a trigger on a > child table, and a trigger on a parent table which was recursively created on > a > child. That makes sense for indexes and constraints, since the objects > persist > if the table is detached, so it doesn't matter how it was defined. > > But if we remove trigger during DETACH, then it's *not* the same as a trigger > that was defined on the child, and I suggest that in v13 we should make that > visible. Hmm, interesting point -- whether the trigger is partition or not is important because it affects what happens on detach. I agree that we should make it visible. Is the proposed single bit "PARTITION" good enough, or should we indicate what's the ancestor table that defines the partition? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
