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

  1. Add primary keys and unique constraints to system catalogs