Andrew Dunstan <[email protected]> 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
