Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
От | Alvaro Herrera |
---|---|
Тема | Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) |
Дата | |
Msg-id | 20190210011654.GA30811@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
|
Список | pgsql-hackers |
On 2019-Feb-09, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > On 2019-Feb-09, Tom Lane wrote: > >> Well, the question that's begged here is exactly why it's okay to > >> remove the trigger and dependency link despite the fact that the > >> constraint needs it. I suppose the answer is that we'll > >> subsequently insert a new trigger implementing the same constraint > >> (and internally-linked to it)? That information is what I'd like > >> to have in the comment. > > > Well, the answer is that the trigger is no longer needed. This is > > an action trigger, i.e. it's attached to the referenced relation; > > and the action is making an independent table become a partition. > > Since the partition is reachable by the action trigger that goes > > through the parent table, we no longer need the action trigger that > > goes directly to the partition. > > Oh ... then why don't we go ahead and get rid of the constraint entry, > too? Because each partition has its own pg_constraint entry. (Otherwise there's no place to put the column numbers into -- they can differ from partition to partition, remember.) The only thing we do is mark it as child of the parent's one. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: