Re: Add primary keys to system catalogs
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Joel Jacobson <joel@compiler.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-02-02T10:49:32Z
Lists: pgsql-hackers
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/
Commits
-
Add primary keys and unique constraints to system catalogs
- dfb75e478cac 14.0 landed