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
