Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I do wonder, however, under what circumstances code would be put into a
> situation where it would add the exact same dependency again, and also
> under what circumstances it would add a dependency between the same
> objects but a different deptype, and how that would work during
> recursive deletion. Now that we have the refobjversion column, the
> presence of duplicate dependencies might be even more dubious. I think
> that could be worth analyzing.
The duplicate-deps case occurs if, say, you use the same function more
than once in a view. While we could probably get rid of dups generated
within the same recordMultipleDependencies call (and maybe already do?),
it's harder to deal with dups made by retail calls. For example,
makeOperatorDependencies doesn't trouble to avoid making duplicate
dependencies when the operator's left and right input types are the
same, or the same as the result type.
The case with almost-dup-but-not-same-deptype *does* occur, for instance
it's very possible to have both normal and automatic dependencies.
As I recall, the policy is to perform the deletion if any of the deps
would allow it.
Dunno about refobjversion; I have my doubts that putting that info in
pg_depend was a sane design choice at all. But from what I understand
of it, wouldn't all deps on a given object necessarily have the same
version?
regards, tom lane
