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: Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-11T19:46:43Z
Lists: pgsql-hackers 
I've pushed this now.  I made one additional change, which was to fix
things so that if both an INTERNAL and an EXTENSION dependency exist,
the first loop will reliably complain about the EXTENSION dependency.
It only takes one more if-test to do that now that we're postponing
the error report till after the loop, and this way we don't need to
split hairs about how likely it is for both to exist.

I think we're done with this thread, though I still need to look at
the problem I complained of in <26527.1549572789@sss.pgh.pa.us>.

			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.