> On Mar 28, 2022, at 2:16 PM, Tom Lane <t...@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. 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