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

From Robert Haas
Subject Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Date
Msg-id CA+TgmoYNeFxdPimiXGL=tCiCXN8zWosUFxUfyDBaTd2VAg-D9w@mail.gmail.com
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Wed, Nov 14, 2018 at 1:28 AM Peter Geoghegan <pg@bowt.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Small performance tweak to run-time partition pruning
Next
From: Paul Ramsey
Date:
Subject: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc