On 2026-02-16 Mo 3:02 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.
Go for it. I'm happy to review.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
