Re: Pro et contra of preserving pg_proc oids during pg_upgrade - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Date
Msg-id CAN-LCVPN+Gy8Fzj3+bsu_if8H-w55ZC2aP0zqktm7LHxP48zQg@mail.gmail.com
Whole thread Raw
In response to Re: Pro et contra of preserving pg_proc oids during pg_upgrade  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Re: Pro et contra of preserving pg_proc oids during pg_upgrade
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound
Next
From: "David G. Johnston"
Date:
Subject: Re: Pro et contra of preserving pg_proc oids during pg_upgrade