public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Andres Freund <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: generating function default settings from pg_proc.dat
Date: Mon, 16 Feb 2026 15:02:03 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <dygomqsjakdjsj7i3ihszz5re2iaayuojzyc3isxm4xxbkl64h@vuujql7tqywm>
References: <[email protected]>
	<lfzlruyq64npjz4z3aiiox2nzg6astxuy5sgmyxm2kwvty4fgq@zcfrpu5jhw5o>
	<[email protected]>
	<dygomqsjakdjsj7i3ihszz5re2iaayuojzyc3isxm4xxbkl64h@vuujql7tqywm>

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.

			regards, tom lane

view thread (18+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: generating function default settings from pg_proc.dat
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox