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-11T01:54:23Z
Lists: pgsql-hackers 
On 2019-Feb-10, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:

> > If we disregard the scenario were people downgrade across minor
> > versions, it's likely possible to produce SQL queries to transform from
> > the old arrangement to the new one, and include those in release notes
> > or a wiki page; not for this week's minors (ENOTIME) but maybe for the
> > next one.
> 
> Dunno ... we couldn't force people to do that, so the server would have to
> be prepared to cope with either arrangement, which seems like an
> impossible mess.

True.

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