Stephen Frost <sfr...@snowman.net> writes: > Apparently I've managed to miss the tricky case..?
That shouldn't be tricky as a user, but has been a tricky subject every time we've been talking about implement Event Triggers in the past two years, so I though I would include it: create schema test create table foo(id serial primary key, f1 text); create event trigger track_table on ddl_command_trace when tag in ('create table', 'alter table', 'drop table') and context in ('toplevel', 'generated', 'subcommand') execute procedure public.track_table_activity(); The trick is that you then want to fire the event trigger for a command in a 'subcommand' context, as seen in the logs provided by the "snitch" example: NOTICE: snitch event: ddl_command_end, context: SUBCOMMAND NOTICE: tag: CREATE TABLE, operation: CREATE, type: TABLE NOTICE: oid: 25139, schema: test, name: foo > Sure, dropping tables, schemas, etc, would have an impact on the values. we don't have, as of yet, support for a 'cascade' context. We will need some heavy refactoring to get there, basically forcing the cascade drops to happen via ProcessUtility(), but having a single DropStmt to handle that I guess it shouldn't be very hard to do. > being told "oh, well, you *could* have been collecting it all along if > you knew about event triggers" isn't a particularly satisfying answer. True that. Now, having at least a way to do that without resorting to hacking the backend or writing a C coded extension sure feels nice enough an answer to me here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers