Re: updates for handling optional argument in system functions
| От | Mark Wong |
|---|---|
| Тема | Re: updates for handling optional argument in system functions |
| Дата | |
| Msg-id | abIyzgOLlB2rpPBP@o обсуждение исходный текст |
| Ответ на | Re: updates for handling optional argument in system functions (Álvaro Herrera <alvherre@kurilemu.de>) |
| Список | pgsql-hackers |
On Tue, Mar 03, 2026 at 05:23:58PM +0100, Álvaro Herrera wrote: > On 2026-Jan-29, Mark Wong wrote: > > > I don't have a solution for the case of a view storing the OID, but Álvaro > > Herrera suggested to me to at least try preventing those OIDs from being > > reused. > > > > I've attached a v3 patch set that introduces src/include/catalog/pg_retired.dat > > to store previously used OIDs and procedure names that the scripts unused_oids > > and renumber_oids.pl can consume to prevent the reuse of retired OIDs. > > Thinking about this again, I wonder where did we get the idea that > reusing OIDs would be a problem. How exactly would this happen? When > you pg_upgrade, your views are taken from a `pg_dump --binary-upgrade` > of the original server, and then recreated using the text > representation of the DDL. We don't pass the function OIDs in any way > from the old server to the new server. And there's no other way (than > pg_upgrade) to go from one major version to the next one where the OID > has been reused. > > So why did we think this was an actual problem? I'm not sure. I think I see the OID of a function get used in some places likes rewriteDefine.c and parse_funcs.c, but I'm not sure if I see a function OID get written out and re-read for a function name lookup in an upgrade code path, yet... Regards, Mark -- Mark Wong <markwkm@gmail.com> EDB https://enterprisedb.com
В списке pgsql-hackers по дате отправления: