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: Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-11T20:04:45Z
Lists: pgsql-hackers 
On 2019-Feb-11, Tom Lane wrote:

> 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>.

Thanks for taking care of this!

-- 
Á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.