On 2026-02-16 Mo 3:02 PM, Tom Lane wrote:
Andres Freund <[email protected]> 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



Reply via email to