On Wed, Feb 18, 2026 at 10:56:56PM +0100, Andreas Karlsson wrote:
> On 1/30/26 1:15 AM, Mark Wong wrote:
> > > Thanks for the patch. After reviewing it, I have mixed feelings. From one side, it removes some redundant code,
whichis good. In the other side, I doubt if we should delete proc entries from pg_proc.c? Say, there is a view that
usesa proc to be deleted, the proc OID is stored with the view, then after an upgrade, the view would be broken. From
thisperspective, should we retain the old proc entries and only point them to the new functions?
> >
> > 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.
> >
> > Maybe that can also be used towards finding that particular solution...
> I am not sure what can be done, breaking people's databases on pg_upgrade is
> certainly not nice and detecting that function oid has been used anywhere in
> a database sounds painful, especially since there are no references to
> system oids in pg_depend, right?
>
> That said this patch should be updated to use the new support for default
> values in BKI files.[1]
>
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=759b03b24ce96f0ba6d734b570d1a6f4a0fb1177
I have attached a new set of patches. v4 is now using the new support for
default values.
Summary of additional changes:
* I've removed the retired OID tracking, but can certainly add that back if we
decide it will be useful
* Caught a bug where I wasn't using BoolGetDatum() with DirectFunctionCall3
with pg_get_expr()
Regards,
Mark
--
Mark Wong <markwkm@gmail.com>
EDB https://enterprisedb.com