Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vsMZ9-001Mn4-1K for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 15:00:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vsMZ8-00AQIv-0V for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 15:00:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vsMZ7-00AQIm-2t for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 15:00:42 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vsMZ5-000000014Tn-1tc0 for pgsql-hackers@postgresql.org; Tue, 17 Feb 2026 15:00:41 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 61HF0VBT1390164; Tue, 17 Feb 2026 10:00:31 -0500 From: Tom Lane To: Corey Huinker cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= , Andres Freund , Andrew Dunstan , PostgreSQL-development Subject: Re: generating function default settings from pg_proc.dat In-reply-to: References: <202602162337.7ye33z25b2jv@alvherre.pgsql> Comments: In-reply-to Corey Huinker message dated "Tue, 17 Feb 2026 03:49:33 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1390162.1771340431.1@sss.pgh.pa.us> Date: Tue, 17 Feb 2026 10:00:31 -0500 Message-ID: <1390163.1771340431@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Corey Huinker 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