Feedback-ID: ia2694551:Fastmail
Date: Mon, 16 Oct 2023 13:36:21 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Nikita Malakhov <hukutoc@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, 
	Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Message-ID: <202310161136.iswfvsuj7v3w@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN-LCVPN+Gy8Fzj3+bsu_if8H-w55ZC2aP0zqktm7LHxP48zQg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202310161136.iswfvsuj7v3w%40alvherre.pgsql>
Precedence: bulk

On 2023-Oct-13, Nikita Malakhov wrote:

> 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.

It is worse than that: the regproc textual representation depends on
search_path.  If you store the text now, the meaning could change later,
depending on the search_path that applies at read time.

Of course, the storage for OID is much shorter and not subject to this
problem; but it is subject to the problem that it breaks if you drop and
replace the function, which could happen for instance in an extensions
upgrade script.

I think a better way to store a function's identity is to store the
'identity' column from pg_identify_object().  It is fully qualified and
you can cast to regprocedure with no ambiguity (which gives you an OID,
if you need one).  And it should upgrade cleanly.

If you have a regproc column that you want to upgrade, maybe it would
work to do 'ALTER TABLE .. SET TYPE TEXT USING' and turn the value into
pg_identify_object().identity.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/