InvokeObjectAccessHook versus DROP INDEX CONCURRENTLY

Just a side note that the above combination doesn't work, at least not
if the object access hook tries to make any database state updates.
I've put a hack into index_drop that should detect the case:
       /*        * We must commit our transaction in order to make the first pg_index        * state update visible to
othersessions.  If the DROP machinery        * has already performed any other actions (removal of other objects,
* pg_depend entries, etc), the commit would make those actions        * permanent, which would leave us with
inconsistentcatalog state        * if we fail partway through the following sequence.  Since DROP        * INDEX
CONCURRENTLYis restricted to dropping just one index that        * has no dependencies, we should get here before
anything'sbeen        * done --- but let's check that to be sure.  We can verify that the        * current transaction
hasnot executed any transactional updates by        * checking that no XID has been assigned.        */       if
(GetTopTransactionIdIfAny()!= InvalidTransactionId)           ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),                   errmsg("DROP INDEX CONCURRENTLY must be first action in
transaction")));

but I wonder exactly what people think they're going to be doing with
object access hooks, and whether the hook call needs to be done
somewhere else instead.
        regards, tom lane