Horton

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
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>
Date: 2019-02-10T01:26:59Z
Lists: pgsql-hackers 
On 2019-Feb-09, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> 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.
> 
> Uh-huh.  And what happens after DETACH PARTITION ... are you going to run
> around and recreate these triggers?

Yep, that's there too.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Redesign the partition dependency mechanism.

  2. Fix trigger drop procedure

  3. Sort the dependent objects before recursing in findDependentObjects().

  4. Avoid sometimes printing both tables and their columns in DROP CASCADE.