Date: Sat, 9 Feb 2019 22:16:54 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <amitlangote09@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Fixing findDependentObjects()'s dependency on scan order
 (regressions in DROP diagnostic messages)
Message-ID: <20190210011654.GA30811@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <32757.1549744015@sss.pgh.pa.us>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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