On Thu, Apr 9, 2020 at 3:09 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > On 2020-Apr-08, Tom Lane wrote: > >> I think that #1 would soon lead to needing all the same infrastructure > >> as we have for inherited columns and constraints, ie triggers would need > >> equivalents of attislocal and attinhcount. I don't really want to go > >> there, so I'd vote for #2. > > > Hmm. Those things are used for the legacy inheritance case supporting > > multiple inheritance, where we need to figure out which parent the table > > is being detached (disinherited) from. But for partitioning we know > > which parent it is, since there can only be one. So I don't think that > > argument applies. > > My point is that so long as you only allow the case of exactly one parent, > you can just delete the child trigger, because it must belong to that > parent. As soon as there's any flexibility, you are going to end up > reinventing all the stuff we had to invent to manage > maybe-or-maybe-not-inherited columns. So I think the "detach" idea > is the first step on that road, and I counsel not taking that step.
As mentioned upthread, we have behavior #1 for indexes (attach existing / detach & keep), without any of the *islocal, *inhcount infrastructure. It is a bit complex, because we need logic to check the equivalence of an existing index on the partition being attached, so implementing the same behavior for trigger is going to have to be almost as complex. Considering that #2 will be much simpler to implement, but would be asymmetric with everything else. -- Amit Langote EnterpriseDB: http://www.enterprisedb.com
