On 20th of July, Robert Haas committed patch:
Make new event trigger facility actually do something. Commit 3855968f328918b6cd1401dd11d109d471a54d40 added syntax, pg_dump, psql support, and documentation, but the triggers didn't actually fire. With this commit, they now do. This is still a pretty basic facility overall because event triggers do not get a whole lot of information about what the user is trying to do unless you write them in C; and there's still no option to fire them anywhere except at the very beginning of the execution sequence, but it's better than nothing, and a good building block for future work. Along the way, add a regression test for ALTER LARGE OBJECT, since testing of event triggers reveals that we haven't got one. Dimitri Fontaine and Robert Haas |
This was preceded (two days earlier) by commit, also by Robert Haas, which stated:
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out. |
What are Event Triggers? These are triggers that run not on INSERT/UPDATE/DELETE/TRUNCATE – i.e. on DML queries, but rather on CREATE/ALTER/DROP commands – that is DDL.
So, how it works?
Commit log says:
...event triggers do not get a whole lot of information about what the user is trying to do unless you write them in C... |
Well, sorry, but I will not write in C just for the benefit of the “Waiting for" series (my C skills are generally very, very limited), so I can only show these limited functions.
Docs show this function as example implementation:
CREATE OR REPLACE FUNCTION snitch() RETURNS event_trigger AS $$ BEGIN RAISE NOTICE 'snitch: % %', tg_event, tg_tag; END; $$ LANGUAGE plpgsql; CREATE EVENT TRIGGER snitch ON ddl_command_start EXECUTE PROCEDURE snitch(); |
These two variables – tg_event and tg_tag are the only things that are accessible to PL/pgSQL triggers now. So, what does it show? I created this trigger in my database, and then ran some DDLs:
$ create table z (i int4); NOTICE: snitch: ddl_command_start CREATE TABLE CREATE TABLE $ alter table z add column j int8; NOTICE: snitch: ddl_command_start ALTER TABLE ALTER TABLE $ create index q on z(j); NOTICE: snitch: ddl_command_start CREATE INDEX CREATE INDEX $ drop table z; NOTICE: snitch: ddl_command_start DROP TABLE DROP TABLE |
You might have noticed that I used “ddl_command_start" in CREATE EVENT TRIGGER statement, and it also was showed.
Currently – there are no other cases that could exist, but in future, I can imagine “ddl_command_end" added.
One important note – you cannot (currently) create triggers for DDL for shared elements (databases, tablespaces, roles).
As you can see – functionality, as accessible from PL/pgSQL, is now limited. But – you can get full functionality by writing your trigger in C (which will be very interesting options for Slony and similar tools).
All in all – its a great addition, missed by many, and long overdue. And since 9.3 development cycle started very recently – I have high hopes of functionality extensions that might be committed before 9.3 will be released.

2 comments
Does this restriction also mean that you cannot access e.g. the name of the table that was created?
@Thomas: tables are not shared. So you can. Not in pl/PgSQL, though.