> 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
