Re: generating function default settings from pg_proc.dat

Corey Huinker <corey.huinker@gmail.com> 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