Re: Pro et contra of preserving pg_proc oids during pg_upgrade
От | Robert Haas |
---|---|
Тема | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
Дата | |
Msg-id | CA+Tgmoah4mG6_edN8F5++Duyjd6gAL48XrnUFj3skpfNTGM0bA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pro et contra of preserving pg_proc oids during pg_upgrade ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Pro et contra of preserving pg_proc oids during pg_upgrade
|
Список | pgsql-hackers |
On Thu, Oct 12, 2023 at 3:36 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > Every catalog has both a natural and a surrogate key. Developers get to use the surrogate key while end-users get to usethe 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 naturalone. 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 arenot even accessible via SQL further reinforces this belief. The only reason to need OIDs as a DBA is to perform joinsamong the catalogs and all such joins are local to the database and even session executing them - the specific valuesare 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
В списке pgsql-hackers по дате отправления: