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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: a(dot)lepikhov(at)postgrespro(dot)ru, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date: 2018-11-15 18:52:29
Message-ID: CA+TgmoYNeFxdPimiXGL=tCiCXN8zWosUFxUfyDBaTd2VAg-D9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 14, 2018 at 1:28 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> We're already relying on the scan order being in reverse chronological
> order, so we might as well formalize the dependency. I don't think
> that it's possible to sort the pg_depend entries as a way of fixing
> the breakage while avoiding storing this extra information -- what is
> there to sort on that's there already? You'd have to infer a whole
> bunch of things about the object types associated with pg_depend
> entries to do that, and teach dependency.c about its callers. That
> seems pretty brittle to me.

I think that the solution that you are proposing sorta sucks, but it's
better than hacking objsubid to do it, which did in fact pass the
laugh test, in that I laughed when I read it. :-)

In a perfect world, it seems to me that what we ought to do is have
some real logic in the server that figures out which of the various
things we could report would be most likely to be useful to the user
... but that's probably a non-trivial project involving a fair amount
of human judgement. Reasonable people may differ about what is best,
never mind unreasonable people. I am inclined to think that your
proposal here is good enough for now, and somebody who dislikes it
(surely such a person will exist) can decide to look for ways to make
it better.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2018-11-15 19:09:07 Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Previous Message Tom Lane 2018-11-15 18:50:38 Re: Small performance tweak to run-time partition pruning