Re: generating function default settings from pg_proc.dat
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Andres Freund <andres@anarazel.de>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-02-17T15:00:31Z
Lists: pgsql-hackers
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. > 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. regards, tom lane
Commits
-
Simplify creation of built-in functions with non-default ACLs.
- f95d73ed4332 19 (unreleased) landed
-
Be more wary of false matches in initdb's replace_token().
- 7664319ccb02 19 (unreleased) landed
-
Simplify creation of built-in functions with default arguments.
- 759b03b24ce9 19 (unreleased) landed