Re: Pro et contra of preserving pg_proc oids during pg_upgrade

Поиск
Список
Период
Сортировка
От Nikita Malakhov
Тема Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Дата
Msg-id CAN-LCVPN+Gy8Fzj3+bsu_if8H-w55ZC2aP0zqktm7LHxP48zQg@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  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Pro et contra of preserving pg_proc oids during pg_upgrade  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Hi,

Textual representation requires a long text field because it could contain schema,
arguments, it is difficult and not effective to be saved as part of the data, and must
be parsed to retrieve function oid. By using direct oid (actually, a value
of the regprocedure field) we avoid it and function could be retrieved by pk.

Why pg_upgrade cannot be used? OID preservation logic is already implemented
for several OIDs in catalog tables, like pg_class, type, relfilenode, enum...
I've mentioned twice that this logic is already implemented and I haven't encountered
any problems with pg_upgrade.

Actually, I've asked here because there are several references to PG_PROC oids
from other tables in the system catalog, so I was worried if this logic could break
something I do not know about.

--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Pro et contra of preserving pg_proc oids during pg_upgrade