On 2026-Oct-12, Färber, Franz-Josef (StMUK) wrote: > Dear Postgres Community, > > pg_event_trigger_ddl_commands after GRANT is quite empty. > > If I execute: GRANT SELECT ON TABLE t TO r; > > . and in a trigger function I have: > > SELECT classid, objid, objsubid, command_tag, object_type, > schema_name, object_identity > FROM pg_event_trigger_ddl_commands(); > > This gives me: > > null, null, null, GRANT, TABLE, null, null > > How to find out the table involved and the privileges?
Yeah, I'm afraid the implementation to expose this to SQL was left incomplete back in 9.5. You can see in EventTriggerCollectGrant() that we do try and collect the information, but in pg_event_trigger_ddl_commands() in event_trigger.c the case for SCT_Grant fills nulls for most columns. The CollectedCommand pointer is present and should contain all details of the grant, though, so as Laurenz says you can get by in the meantime with some C code. Exposing it in SQL (which we're likely to require now that Sawada-san is back at implementing DDL replication) is going to require some additional design for the datatypes and so on. The difference between GRANT and all others is that you affect multiple objects and multiple privileges in a single command, so we cannot just shoehorn an object name in the same place as for the other commands. One weird thing I noticed is that there isn't a single GRANT in the tests in src/test/modules/test_ddl_deparse. But that wouldn't have changed things at all, I'm afraid ... (You could use the code there as a template to implement your own, BTW.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
