Re: Granting SET and ALTER SYSTE privileges for GUCs

Mark Dilger <mark.dilger@enterprisedb.com> writes:
> [ v15 patch ]

Thanks.  As I'm working through this, I'm kind of inclined to drop
the has_parameter_privilege() variants that take an OID as object
identifier.  This gets back to the fact that I don't think
pg_parameter_acl OIDs have any outside use; we wouldn't even have
them except that we need a way to track their role dependencies
in pg_shdepend.  AFAICS users will only ever be interested in
looking up a GUC by name.  Any objections?

Another thought here is that I see you're expending some code
to store the canonical name of a GUC in pg_parameter_acl, but
I think that's probably going too far.  In particular, for the
legacy mixed-case names like "DateStyle", what ends up in the
table is the mixed-case name, which seems problematic.  It would
definitely be problematic if an extension used such a name,
because we might or might not be aware of the idiosyncratic
casing at the time a GRANT is issued.  I'm thinking that we
really want to avoid looking up custom GUCs at all during GRANT,
because that can't do anything except create hazards.

So I think that instead of what you've got here, we should
(1) apply the map_old_guc_names[] mapping, which is constant
    (for any one PG release anyway)
(2) smash to lower case
(3) verify validity per valid_variable_name.

This also simplifies life on the lookup side, where it's sufficient
to do steps (1) and (2) before performing a catalog search.

Thoughts?

            regards, tom lane