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