| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
| Date: | 2023-10-12 20:16:40 |
| Message-ID: | CA+Tgmoah4mG6_edN8F5++Duyjd6gAL48XrnUFj3skpfNTGM0bA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 12, 2023 at 3:36 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> Every catalog has both a natural and a surrogate key. Developers get to use the surrogate key while end-users get to use the natural one (i.e., the one they provided). I see no reason to change that specification.
I agree with this.
> And I do believe there are no compelling reasons for an end-user to need to use the surrogate key instead of the natural one.
But I disagree with this.
> The example provided by the OP isn't one, IMO, the overall goal can be accomplished via the natural key (if it cannot, maybe we need to make retrieving the natural key for a pg_proc record given an OID easier). The fact that OIDs are not even accessible via SQL further reinforces this belief. The only reason to need OIDs as a DBA is to perform joins among the catalogs and all such joins are local to the database and even session executing them - the specific values are immaterial.
This just all seems very simplistic to me. In theory it's true, but in
practice it isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikita Malakhov | 2023-10-12 20:30:53 | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
| Previous Message | Robert Haas | 2023-10-12 20:10:27 | Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound |