Re: generating function default settings from pg_proc.dat

I wrote:
> 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.

Here's a draft patch for that. It's pretty simple in concept: in
bootstrap mode, let aclitemin() look into a hard-wired table of role
names, just as we do for pg_type data before that catalog has been
loaded. Everything then basically just works. However, the project
bloated on me a little bit, because after removing all the function
revoke/grant commands from system_functions.sql, I was left with

GRANT pg_read_all_settings TO pg_monitor;
GRANT pg_read_all_stats TO pg_monitor;
GRANT pg_stat_scan_tables TO pg_monitor;

There was some excuse for those to live in system_functions.sql
as long as they were beside grants establishing special privileges
for those roles, but with those grants gone this seemed like an
unacceptably random place for them. So I moved that knowledge
into a new catalog data file pg_auth_members.dat.

This accomplishes the goal Andres had of eliminating pg_proc
update operations during initdb, except for the new-style
SQL-language functions set up in system_functions.sql:

postgres=# select xmin, oid, oid::regprocedure from pg_proc where xmin != 1 and prosqlbody is null;
xmin | oid | oid
------+-------+-------------------------------------------------------
261 | 14095 | dsnowball_init(internal)
262 | 14096 | dsnowball_lexize(internal,internal,internal,internal)
459 | 14161 | information_schema._pg_expandarray(anyarray)
612 | 14511 | plpgsql_call_handler()
612 | 14512 | plpgsql_inline_handler(internal)
612 | 14513 | plpgsql_validator(oid)
(6 rows)

However, I'm not sure I love it in this form, because what it
asks developers to do is populate proacl using aclitemin's
notation, eg

@@ -8602,7 +8641,8 @@
provolatile => 'v', prorettype => 'record', proargtypes => '',
proallargtypes => '{text,int8,int8,int8}', proargmodes => '{o,o,o,o}',
proargnames => '{name,off,size,allocated_size}',
- prosrc => 'pg_get_shmem_allocations' },
+ prosrc => 'pg_get_shmem_allocations',
+ proacl => '{postgres=X/postgres,pg_read_all_stats=X/postgres}' },

{ oid => '4099', descr => 'Is NUMA support available?',
proname => 'pg_numa_available', provolatile => 's', prorettype => 'bool',

That's verbose, and not very pretty, and potentially confusing because
it's predicated on the assumption that the bootstrap user's name is
'postgres'. This patch does work when the bootstrap user's name is
something else, but I don't really like hard-wiring things that way.

Is it worth putting in some additional kluge to allow this field
to be spelled in a different way, and if so what notation do we
want to adopt?

One thing we could do for free is to drop the "/postgres" grantor
notations, since aclitemin will default to assuming the grantor
is the bootstrap superuser. That makes things more compact but
doesn't move the needle far otherwise.

Another potential objection is specific to the functions that
underlie system views: before, their special grants/revokes lived
beside similar grants for the associated views. Now those are in
two different files with completely different notations. So maybe
this has taken the "single source of truth" idea too far, and we
should leave system_views.sql alone.

Comments welcome.

regards, tom lane