On 2021-01-22 16:42, Tom Lane wrote:
>> pg_depend
>> pg_shdepend
> Yeah, this is noted in the patch's own regression tests.
>
>> Wouldn't it be possible to add primary keys to these two as well?
> Neither of the existing indexes is suitable, not being unique.
>
> We could imagine adding a unique index across the whole column set,
> but that would be an awfully large price to pay for neatnik-ism.
> Also, at least for pg_depend (less sure about pg_shdepend), some code
> cleanup would be required, because I don't think that we try very
> hard to avoid making duplicate dependency entries. On the whole
> I feel this'd be counterproductive.
I did attempt to make a six- or seven-column unique constraint on
pg_depend a while ago. This fails pretty much immediately during
initdb. None of the code that adds dependencies, in particular
recordMultipleDependencies(), checks if the dependency is already there.
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.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
