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

On Thu, Dec 6, 2018 at 8:52 PM Andrey Lepikhov
<a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
> I want to say that we need to localize the rules for the order of the
> diagnostic messages as much as possible in dependency.c.

But the issue *isn't* confined to dependency.c, anyway. It bleeds into
a couple of other modules, like extension.c and tablecmds.c.

> > messages that are represented in the regression tests. Anyway, I don't
> > think it's acceptable to change the messages like this. It makes them
> > much less useful.
>
> May you clarify this? If I understand correctly, your solution is that
> user receives a report about the last inserted internal dependency on
> the object. Why the full info about internal dependencies of the object
> much less useful?

I don't know why for sure -- I just know that it is. It must have
evolved that way, as software often does. It's not surprising that the
most recently entered dependency is usually the most marginal among
dependencies of equal precedence in the real world, and therefore the
best suggestion. I've shown this with two examples.

To return to one of the examples: are you arguing that there is no
practical difference between "you need to drop the object on the
partition parent instead of its child" and "instead of dropping the
trigger on the partition child, maybe drop the child itself"? I think
it's *extremely* obvious that there is a big practical difference to
users in that particular case. Now, I agree that there are many other
examples where it doesn't really matter to users, but I don't think
that that's very relevant. Yes, these are the exceptions, but the
exceptions are often the interesting cases.

> During the retail index tuple deletion project (heap cleaner subsystem)
> we have non-fixed order of tuples at database relations. This caused to
> unsteady order of text strings in some check-world test results.
> Thus, I realized that the order of messages in the test results is
> mostly a game of chance. For this reason I think it is necessary to find
> more general solution of the messages ordering problem.

I have no idea what you mean here. I'm proposing a patch that stops
it being a game of chance, while preserving the existing
slightly-random behavior to the greatest extent possible. I think that
my patch would have stopped that problem altogether. Are you
suggesting that it wouldn't have?

--
Peter Geoghegan