On Tue, Feb 17, 2026 at 10:00 AM Tom Lane <[email protected]> wrote:
> Corey Huinker <[email protected]> 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.
