Re: generating function default settings from pg_proc.dat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generating function default settings from pg_proc.dat
Date: 2026-02-17 15:00:31
Message-ID: 1390163.1771340431@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-02-17 15:13:43 Re: generating function default settings from pg_proc.dat
Previous Message Tomas Vondra 2026-02-17 13:39:15 Re: index prefetching