Re: generating function default settings from pg_proc.dat

On Tue, Feb 17, 2026 at 10:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> > I like this a lot too, but I'm noticing that with each iteration we're
> > getting closer to re-inventing SQL.
>
> Really? Neither pg_proc.dat nor the constructed postgres.bki file
> look anything like SQL to my eye.
>

It doesn't _look_ like SQL, but we're trying to cover all things that a
CREATE FUNCTION can do, and if we don't model them all, then we're back to
needing CREATE OR REPLACE overlays.

> > Would it make sense in the long run to
> > have a mode on the CREATE FUNCTION command that cues initdb to create the
> > minimal function skeleton with prescribed oid on the first pass, but then
> > stores the defer-able parts (if any) for a later pass, perhaps in
> parallel?
>
> I seriously, seriously doubt it. That would involve allowing large
> amounts of the parser to run in bootstrap mode, and would probably
> end in plastering warts all over backend/parser/ to say "do this
> in one way normally but some other way in bootstrap". Also, it's
> really just syntactic sugar and does nothing for the harder problems
> that bootstrap mode has to solve, such as supporting references to
> objects that've not been created yet.
>

Fair enough. But in the interest of keeping a single source of truth, what
if we reversed the process, having a build-time perl script parse
system_functions.sql to build a minimal pg_proc.dat-like file just for
bootstrap? We would probably want to break up system_functions.sql into
several files, (admin functions go here, adt-related functions go there,
etc), but we'd have total clarity on all function definitions, and we
wouldn't have to modify the generation of pg_proc.dat unless a new function
syntax feature affected bootstrapping.