public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Corey Huinker <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: generating function default settings from pg_proc.dat
Date: Wed, 18 Feb 2026 14:33:02 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CADkLM=dYk8tgRUhLmU25pPvFU=uO8dktwHdrb+06a5y1w7nSng@mail.gmail.com>
References: <dygomqsjakdjsj7i3ihszz5re2iaayuojzyc3isxm4xxbkl64h@vuujql7tqywm>
	<[email protected]>
	<CADkLM=cJkVqeP2iQW9ghdxYG51zPPTwZKYB2+_m=TFBnyOSMfw@mail.gmail.com>
	<[email protected]>
	<CADkLM=dYk8tgRUhLmU25pPvFU=uO8dktwHdrb+06a5y1w7nSng@mail.gmail.com>

Corey Huinker <[email protected]> writes:
> 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.

Seems like an awful lot of work compared to the benefit.  We are
down to two kinds of entries in system_functions.sql:

1. New-style SQL-language functions.  To my mind, for those functions
system_functions.sql *is* the source of truth; the pg_proc entry is
vestigial and present mostly to reserve the OID.  If we decided it's
okay to not have nailed-down OIDs for those functions, we could drop
their pg_proc entries altogether.  But even as things stand, those
entries all say
    prosrc => 'see system_functions.sql' },
which I think makes it pretty clear where the primary definition is.

2. GRANT/REVOKE operations.  Andres muttered something about trying
to integrate those into pg_proc.dat too, and I'm going to go look
at the idea.

			regards, tom lane

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: generating function default settings from pg_proc.dat
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox