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.