Re: updates for handling optional argument in system functions
Mark Wong <markwkm@gmail.com>
From: Mark Wong <markwkm@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Chao Li <li.evan.chao@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2026-03-12T03:28:14Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Simplify creation of built-in functions with default arguments.
- 759b03b24ce9 19 (unreleased) cited