On 5 December 2012 22:49, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 5 December 2012 22:21, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: >>> Simon Riggs <si...@2ndquadrant.com> writes: >>>>> CREATE EVENT TRIGGER my_event_trigger >>>>> ON table_rewrite >>>>> EXECUTE PROCEDURE consider_whether_to_throw_an_error(); >>>> >>>> +1, I was just thinking that myself. >>> >>> +1, and I think that can happen for 9.3, as soon as we agree on the list >>> of code points where we want that event to fire. ALTER TABLE variants >>> that are rewriting the heap, sure. CLUSTER? VACUUM FULL? TRUNCATE? >> >> Events needed >> * Table rewrite >> * Index rebuild >> * Relation scan (index/table/toast etc) >> * AccessExclusiveLock > > For each of those events we need to find the exact code location from > where to call the registered user defined function, if any. I would like > us to at least devise which commands are going to fire the events here. > > Table Rewrite: ALTER TABLE, CLUSTER, VACUUM… ? > Index Rebuild: ALTER TABLE, REINDEX, CLUSTER, VACUUM FULL… ?
yes please > Relation scan: SELECT, ALTER TABLE … ADD CHECK …, etc > > maybe targeting index/seq scan from the executor code > directly would be enough in that case? I'm not sure I > can call into src/backend/commands/event_trigger.c > from anywhere in the executor though, I need advice Not SELECT - DDL only - for things like CREATE INDEX, so IndexBuildScan() IIRC > AccessExclusiveLock on a relation when taken by *any* command? before > the lock is taken I suppose… At end of Lock Acquire, same place we already WAL-log the action. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
