Alvaro, hi:
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
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
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;")
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
?
Thanks,
Andrei.
On 2019-12-23 08:36, Alvaro Herrera wrote:
> On 2019-Dec-22, PG Bug reporting form wrote:
>
>> 1. use case is to delete rows with oid references to the table before
>> "drop
>> table"
>
> I think you could achieve that with an event trigger on event sql_drop.
> IIRC that event trigger is run for the objects before the drops are
> actually executed.
>
> ddl_command_start is pretty useless, because it doesn't have much info
> abot the command being run; I'm sure that
> pg_event_trigger_ddl_commands() would always return empty there.
> The function would return non-empty only during ddl_command_end, but
> that's no useful to you because the drops will already have run.