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
