Re: generating function default settings from pg_proc.dat

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2026-02-16 Mo 3:02 PM, Tom Lane wrote:
>> Who's going to work on this?  I'm happy to take a swing at it,
>> but don't want to duplicate someone else's effort.

> Go for it. I'm happy to review.

After a little bit of thought, I propose the following sketch
for what to do in the bootstrap backend:

In InsertOneValue(), add a special case for typoid == PG_NODE_TREEOID.
pg_node_tree_in() would just fail anyway so this isn't removing
any useful functionality.  The special-case code would check which
column we are entering a value for and dispatch to appropriate code:

       if (typoid == PG_NODE_TREEOID)
       {
           if (RelationGetRelid(boot_reldesc) == ProcedureRelationId &&
	       i == Anum_pg_proc_proargdefaults - 1)
	       values[i] = ConvertOneProargdefaultsValue(value);
	   else
	       ... maybe other cases later
	   else
	       elog(ERROR, "can't handle pg_node_tree input");
	   return;
       }

This framework would permit special-casing other catalog columns
in future, if we feel a need for that.

Andres was concerned about not having access to the other columns of
pg_proc, but I think that's mistaken: bootstrap.c's values[] array
should hold the already-parsed values of all earlier columns for the
current entry.  So ISTM that we should have enough data to interpret
an input that just looks like an array of input-value strings and
construct a List of Const nodes from that, then flatten it to a
nodetree string.

So with that we'd have enough infrastructure to allow writing
something like

	proargdefaults => '{1,2,true}'

This seems orthogonal to Andres' suggestion about refactoring
the pg_proc.dat representation of arguments to not be parallel
arrays but a list of hashes.  I think that's likely a good
idea, but I don't want to implement it because I'm not a great
Perl programmer.  Do you want to pick up that part?

			regards, tom lane