From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Andrew Dunstan <andrew@dunslane.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: generating function default settings from pg_proc.dat
In-reply-to: <dygomqsjakdjsj7i3ihszz5re2iaayuojzyc3isxm4xxbkl64h@vuujql7tqywm>
References: <183292bb-4891-4c96-a3ca-e78b5e0e1358@dunslane.net> <lfzlruyq64npjz4z3aiiox2nzg6astxuy5sgmyxm2kwvty4fgq@zcfrpu5jhw5o> <1166845.1771269225@sss.pgh.pa.us> <dygomqsjakdjsj7i3ihszz5re2iaayuojzyc3isxm4xxbkl64h@vuujql7tqywm>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 16 Feb 2026 14:47:07 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1172934.1771272123.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Feb 2026 15:02:03 -0500
Message-ID: <1172935.1771272123@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1172935.1771272123%40sss.pgh.pa.us>
Precedence: bulk

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 t=
he
> 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 p=
g_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 proargty=
pes
> and proallargtypes/proargmodes/... having a different input syntax.  I'v=
e
> spent too much time trying to keep the arguments of stats functions in s=
ync.

Agreed, we could stand to do that better.

>   proargs =3D> [
>      {type =3D> 'name', name =3D> 'slot_name'},
>      {type =3D> 'name', name =3D> 'plugin'},
>      {type =3D> 'bool', name =3D> 'temporary', default =3D> 'false'},
>      {type =3D> 'bool', name =3D> 'twophase', default =3D> 'false'},
>      {type =3D> 'bool', name =3D> 'failover', default =3D> 'false'},
>   ],
>   prorettype =3D> [
>      {type =3D> 'name', name =3D> 'slot_name'},
>      {type =3D> 'pg_lsn', name =3D> '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