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

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.