From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add primary keys to system catalogs |
Date: | 2021-01-19 10:46:55 |
Message-ID: | e691a22bb4e2d1074c29828f5e65946b7e98b502.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2021-01-17 at 17:07 -0500, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-01-19 10:50:38 | Re: [patch] Help information for pg_dump |
Previous Message | Amit Kapila | 2021-01-19 10:32:18 | Re: TOAST condition for column size |