Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date
Msg-id 13445.1549832789@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-10, Peter Geoghegan wrote:
>> On Sun, Feb 10, 2019 at 8:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Just to be be clear, my inclination is to do nothing about this in v11.
>>> It's not apparent to me that any fix is possible given the v11 dependency
>>> data, at least not without downsides that'd likely outweigh the upsides.
>>> We've not seen field complaints about these problems.

>> I thought that you might have had a trick up your sleeve for v11,
>> although I had no idea how that would be possible without making sure
>> that partition dependencies came in pairs to begin with.  :-)

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

            regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Next
From: Daniel Gustafsson
Date:
Subject: Re: Reporting script runtimes in pg_regress