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: <lfzlruyq64npjz4z3aiiox2nzg6astxuy5sgmyxm2kwvty4fgq@zcfrpu5jhw5o>
References: <183292bb-4891-4c96-a3ca-e78b5e0e1358@dunslane.net> <lfzlruyq64npjz4z3aiiox2nzg6astxuy5sgmyxm2kwvty4fgq@zcfrpu5jhw5o>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 16 Feb 2026 13:54:49 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1166844.1771269225.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Feb 2026 14:13:45 -0500
Message-ID: <1166845.1771269225@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1166845.1771269225%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> I wish we could just generate the parse-analyzed representation for defa=
ult
> values during bootstrap, but that's probably not realistic.

> Although, I guess we don't really need the full machinery. Afaict we jus=
t need
> a list of simple CONST nodes.

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 suppose it might be possible to rethink the printed representation
of Const nodes to dodge that problem, but that's starting to make the
project seem rather complex.  Even without that, hand-maintained
byte-level representations of jsonb, float8, text[] seem like a pretty
bad idea.

I think what we'd really want here is some smarts in backend bootstrap
mode to be able to invoke the correct datatype input function to
convert the type's standard string representation into a Datum.
I wonder how complicated that'd be.

			regards, tom lane