Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-10T01:25:37Z
Lists: pgsql-hackers 
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?

			regards, tom lane

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.