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