> On Apr 4, 2022, at 2:26 PM, Tom Lane <t...@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
