Re: Add primary keys to system catalogs
От | Peter Eisentraut |
---|---|
Тема | Re: Add primary keys to system catalogs |
Дата | |
Msg-id | 2bc9a79e-cc70-a4bb-9083-8007104105e2@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Add primary keys to system catalogs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add primary keys to system catalogs
Re: Add primary keys to system catalogs |
Список | 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/
В списке pgsql-hackers по дате отправления: