On Tue, Feb 17, 2026 at 10:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Corey Huinker <corey.huinker@gmail.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.
