RE: Collect ALTER PUBLICATION commands for event triggers

On Friday, July 24, 2026 10:07 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> I found two cases where ALTER PUBLICATION fires ddl_command_end, but
> pg_event_trigger_ddl_commands() does not report the corresponding ALTER
> PUBLICATION command.
>
> Attached are two patches.
>
> 0001 patch: Collect ALTER PUBLICATION mapping drops
>
> When an ALTER PUBLICATION command only removes publication
> membership mappings, the publication itself is not collected as a
> ddl_command_end object.
>
> For example:
> ALTER PUBLICATION p DROP TABLE t1;
> ALTER PUBLICATION p SET TABLE t2;
>
> sql_drop reports the removed publication relation, but
> pg_event_trigger_ddl_commands() reports no corresponding ALTER
> PUBLICATION entry. This seems like a bug to me. Thoughts?

I suspect this wasn't caught earlier because handling the dropped publication
relation was sufficient to deparse it into the original ALTER PUBLICATION
command (by combining multiple dropped items). I also assumed the primary use
case for the event trigger was deparsing. I'm not opposed to also catching this
command in ddl_end - I'm just curious whether it would address any additional
use cases beyond what's already covered.

> I think this should be backpatched to all supported branches. But, if the above
> behavioral change is considered too risky for backpatching, though, I'm fine
> with applying it only to master. Thoughts?
>
>
> 0002: Collect ALTER PUBLICATION SET ALL changes
>
> ALTER PUBLICATION ... SET ALL TABLES and SET ALL SEQUENCES have a
> similar issue. These commands fire ddl_command_end, but
> pg_event_trigger_ddl_commands() can return no entry.
>
> 0002 patch fixes the issue by making AlterPublicationAllFlags() report whether
> the publication state changed. If it did, the publication itself is collected as the
> ALTER PUBLICATION command.

+1 for addressing this. Without handling this command, there is no alternative
means to deparse it into the original ALTER PUBLICATION SET ALL statement.

>
> As a side-effect of this fix, SET ALL TABLES ... EXCEPT (...) may now produce
> both a publication-level entry and the existing per-membership entries for
> added exclusions. This is intentional, since they represent different parts of
> the command.

Best Regards,
Zhijie Hou