Re: Granting SET and ALTER SYSTE privileges for GUCs

> On Apr 4, 2022, at 2:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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?

None.

> 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.

Yikes.  It took a few tries to see what you mean.  Yes, if the GRANT happens before the LOAD, that can have bad
consequences. So I agree something should be changed. 

> 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?

That sounds right.  Do you already have something like that coded, or would you like me to post a patch?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company