Re: Add primary keys to system catalogs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-01-21T17:15:56Z
Lists: pgsql-hackers
Attachments
- catalog-primary-keys-comments.patch (text/x-diff) patch
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 2021-01-17 23:07, Tom Lane wrote: >> I've reviewed this patch. It looks pretty solid to me, with a couple >> trivial nits as mentioned below, and one bigger thing that's perhaps >> in the category of bikeshedding. Namely, do we really want to prefer >> using the OID indexes as the primary keys? > I chose this because the notional foreign keys point to the OID. > If you design some basic business database with customer IDs, product > IDs, etc., you'd also usually make the ID the primary key, even if you > have, say, a unique constraint on the product name. But this is of > course a matter of taste to some degree. Fair enough. As I said upthread, I just wanted to be sure we'd considered the alternative. I'm content to use the OIDs as pkeys, although I think that decision should be explicitly recorded somewhere (cf attachment). >> The contents of system_constraints.sql seem pretty randomly ordered, >> and I bet the order isn't stable across machines. > They follow the order in which the catalogs are processed byt genbki.pl. Looking closer, I see the data structure is an array not a hash, so I withdraw the concern about instability. After reading the patch again, I have a couple more nits about comments, which I'll just present as a proposed delta patch. Otherwise it's good. I'll mark it RFC. regards, tom lane
Commits
-
Add primary keys and unique constraints to system catalogs
- dfb75e478cac 14.0 landed