As stated by Postgres' event trigger firing matrix both ddl_command_end and sql_drop is triggered for ALTER TABLE and ALTER FOREIGN TABLE statements, further analysis shows that sql_drop is only fired for certain drop-related table alterations (ALTER TABLE ... DROP COLUMN..., ALTER TABLE ... DROP CONSTRAINT..., possibly others). Due to how ClassDB processes these events, these drop-related table alterations result in duplicate log entries when ClassDB is run on Postgres versions >9.4 (they are not added for versions below 9.5 because all sql_drop events are ignored in versions <9.5).
Given that other drop events do not result in duplicate entries, it seems that pg_event_trigger_ddl_commands().object_identity is not NULL for any ALTER TABLE / ALTER FOREIGN TABLE events, even if they are drop-related and therefore sql_drop was fired just before.
Here is a sequence of events and SELECTS from myddlactivity that show duplicate entries for the statement ALTER TABLE testtable DROP COLUMN col2; in pg9.6:
As stated by Postgres' event trigger firing matrix both
ddl_command_end
andsql_drop
is triggered forALTER TABLE
andALTER FOREIGN TABLE
statements, further analysis shows thatsql_drop
is only fired for certain drop-related table alterations (ALTER TABLE ... DROP COLUMN...
,ALTER TABLE ... DROP CONSTRAINT...
, possibly others). Due to how ClassDB processes these events, these drop-related table alterations result in duplicate log entries when ClassDB is run on Postgres versions >9.4 (they are not added for versions below 9.5 because allsql_drop
events are ignored in versions <9.5).Given that other drop events do not result in duplicate entries, it seems that
pg_event_trigger_ddl_commands().object_identity
is notNULL
for anyALTER TABLE
/ALTER FOREIGN TABLE
events, even if they are drop-related and thereforesql_drop
was fired just before.Here is a sequence of events and SELECTS from
myddlactivity
that show duplicate entries for the statementALTER TABLE testtable DROP COLUMN col2;
in pg9.6: