Re: BUG #16177: pg_event_trigger_ddl_commands() returns empty set for ddl_command_start and "drop table"

Hello,

On 2019-Dec-23, Andrei Pozolotin wrote:

> 1. thank you for the idea, I have just tried that
>
> 2. I could not make it work, since "sql_drop" event
> happens **after** the "drop table" has already being attempted
> and failed due to table oid dependencies

Well, that's really disappointing, but now that you say it, I remember
that yes we had to save all table info prior to firing the trigger
because it (the trigger) would run after the drop. I think there was a
restriction that forced us to do things that way, but TBH I don't
remember clearly.

> 3. you may find it curious that I was in fact trying to improve on the
> following trigger function:
> https://github.com/2ndQuadrant/pglogical#automatic-assignment-of-replication-sets-for-new-tables
> to make it work for "drop table" as well

That makes sense.

> 4. my current workaround is to move trigger logic for "create table"/"drop
> table"
> outside of postgre into the app layer, essentially doing via execute()
> intercept:
> * replicate_ddl_command("create table; replication_set_add_table();")
> * replicate_ddl_command("replication_set_remove_table(); drop table;")

That seems a decent workaround, if suboptimal.

> 5. nonetheless, can you suggest any other way to make "event_trigger" work
> for this scenario:
> https://github.com/2ndQuadrant/pglogical#automatic-assignment-of-replication-sets-for-new-tables
> ?

I wonder if it's possible for pglogical to register pg_depend entries to
the replication set, so that the repset membership is dropped alongside
the table.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services