Re: Add primary keys to system catalogs - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: Add primary keys to system catalogs
Date
Msg-id 3aef6612-ea31-0fae-34fe-81505dff4549@postgresfriends.org
Whole thread Raw
In response to Re: Add primary keys to system catalogs  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
On 1/19/21 11:46 AM, Laurenz Albe wrote:
> On Sun, 2021-01-17 at 17:07 -0500, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> [ v2-0001-Add-primary-keys-and-unique-constraints-to-system.patch ]
>>
>> [...] do we really want to prefer
>> using the OID indexes as the primary keys?  In most cases there's some
>> other index that seems to me to be what a user would think of as the
>> pkey, for example pg_class_relname_nsp_index for pg_class or
>> pg_proc_proname_args_nsp_index for pg_proc.  Preferring OID where it
>> exists is a nice simple rule, which has some attractiveness, but the
>> OID indexes seem to me like a lookup aid rather than the "real" object
>> identity.
> 
> I disagree.  The OID is the real, immutable identity of an object.
> The "relname" of a "pg_class" encatalogtry can change any time.
> Since there are no foreign keys that reference catalogs, that won't cause
> problems, but I still think that primary keys should change as little as
> possible.

This might be good advice for systems where the primary key defines the
physical layout of the table, but for postgres's heap there is no reason
not to prefer the natural key of the table.

My vote is with Tom on this one.
-- 
Vik Fearing



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Online checksums patch - once again
Next
From: Michael Paquier
Date:
Subject: Re: Paint some PG_USED_FOR_ASSERTS_ONLY in inline functions of ilist.h and bufpage.h