On Thu, Dec 6, 2018 at 8:52 PM Andrey Lepikhov <a.lepik...@postgrespro.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
