Re: Granting SET and ALTER SYSTE privileges for GUCs

> On Mar 28, 2022, at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Yeah, I know it's *possible* to make this work.  The question is why is
> it good to do it like this rather than to use the string API, now that
> we have the latter.  AFAICS this way just guarantees that the hook must
> do a catalog lookup in order to figure out what you're talking about.

Ok, thanks for clarifying.  I took the *HookStr versions of the hooks to be an alternative to be used when no Oid was
present,something of a last resort.  I never thought much about using them under other circumstances. 

> The core point here is that the actual identity of a GUC is its name.
> Any OID that may exist in pg_parameter_acl is just a nonce alias that
> means nothing to anybody.  Anyone who's trying to, say, enforce that
> Joe Blow can't change shared_buffers is going to need to see the GUC
> name.  (I am, btw, busy doing a lot of renaming in the patch to try
> to clarify that these OIDs are not identifiers for GUCs; imagining
> that they are just risks confusion.)

I was about to write another patch using the HookStr form, but if you are already editing, then I'll let you make the
change. I don't see a problem with what you are proposing. 

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