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/
