| From: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 21:57:53 |
| Message-ID: | CAN-LCVPN+Gy8Fzj3+bsu_if8H-w55ZC2aP0zqktm7LHxP48zQg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
https://postgrespro.ru/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2023-10-12 22:28:51 | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
| Previous Message | Peter Geoghegan | 2023-10-12 21:52:38 | Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound |