Re: Granting SET and ALTER SYSTE privileges for GUCs

> On Mar 28, 2022, at 2:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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. Upthread there was some discussion of a hook not being able to assume a snapshot and working transaction, and hence not being able to query the catalogs. I would think that in a GRANT or REVOKE that hasn't already errored, the hook would have a transaction and could look up whatever it likes? There is a CommandCounterIncrement() call issued in objectNamesToOids() for new parameters, so by the time the hook is running it should be able to see the parameter.

Am I reasoning about this the wrong way?

> ... or, for that matter, why is there any such call at all?
> No other GRANT/REVOKE operation calls such a hook.

I think ALTER DEFAULT PRIVILEGES does, though that's not quite the same thing. I don't have a strong opinion on this. Joshua, what's your take?

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