Re: AW: pg_event_trigger_ddl_commands after GRANT is quite empty

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Färber, "Franz-Josef (StMUK)" <Franz-Josef(dot)Faerber(at)stmuk(dot)bayern(dot)de>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: AW: pg_event_trigger_ddl_commands after GRANT is quite empty
Date: 2026-10-13 11:10:05
Message-ID: 410d484fe9afbac8dd2c67c67db5fd73a589da3e.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2026-10-12 at 14:36 +0000, Färber, Franz-Josef (StMUK) wrote:
> > > 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?
> >
> > I think you have to write a C function that can do something with pg_ddl_command.
>
> A solution usable from SQL or plpgsql would've been nice.

Indeed. I am surprised that the table is not reported for a GRANT
statement. Perhaps it is because GRANT operates on all kinds of objects,
not sure. You could write a patch for PostgreSQL to improve that.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dominique Devienne 2026-10-13 11:28:46 Re: PostgreSQL 17: RLS, SECURITY DEFINER and migration role safety questions
Previous Message Laurenz Albe 2026-10-13 11:06:01 Re: Why is materialized view creation a "security-restricted operation"?