Re: generating function default settings from pg_proc.dat

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2026-02-16 14:13:45 -0500, Tom Lane wrote:
>> Const is enough to be problematic. In particular, the bytes of the
>> stored Datum are shown in physical order so that the results are
>> endian-dependent. We can't have machine dependencies in postgres.bki.

> I was more thinking we would teach bootstrap.c/bootparse.y to generate the
> List(Const+) from a simpler representation that would be included in
> postgres.bki, rather than include the node tree soup in postgres.bki.

Right, maintaining pg_node_tree strings is exactly what we don't want
to do.

> Looks like the slightly difficult bit is that we haven't assembled the pg_proc
> row by the time we'd do the OidInputFunctionCall() in InsertOneValue(), so
> we'd not trivially know the type of the corresponding column.

Ah, I'd not got far enough to notice that.

> But if we made the input something like {'some'::type1, 'value'::type2}, we
> wouldn't need to know the corresponding column's type, and genbki could build
> it.

Hmm. Your idea of a bespoke 'proc' command would avoid the need for
duplication, I think, although I'm not sure how to write that without
it becoming its own source of maintenance pain.

> Particularly for SRFs, I find it rather painful to keep proargtypes,
> proallargtypes, proargmodes, proargnames in sync. Not helped by proargtypes
> and proallargtypes/proargmodes/... having a different input syntax. I've
> spent too much time trying to keep the arguments of stats functions in sync.

Agreed, we could stand to do that better.

> proargs => [
> {type => 'name', name => 'slot_name'},
> {type => 'name', name => 'plugin'},
> {type => 'bool', name => 'temporary', default => 'false'},
> {type => 'bool', name => 'twophase', default => 'false'},
> {type => 'bool', name => 'failover', default => 'false'},
> ],
> prorettype => [
> {type => 'name', name => 'slot_name'},
> {type => 'pg_lsn', name => 'lsn'},
> ]
> }

I'd be inclined to keep prorettype separate from the output
arguments, but otherwise something like this seems attractive.

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.

regards, tom lane