Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> On Mar 28, 2022, at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I just came across something odd in v12 that is still there in v13:
>> ExecGrant_Parameter uses InvokeObjectPostAlterHook not
>> InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
>> Is there a good argument for it?
> For SET and ALTER SYSTEM, the target of the action may not have an entry
> in pg_parameter_acl, nor an assigned Oid anywhere, so the only
> consistent way to pass the argument to the hook is by name. For
> GRANT/REVOKE, the parameter must have an Oid, at least by the time the
> hook gets called.
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.
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.)
regards, tom lane