Re: Event Triggers reduced, v1

On Thu, Jul 12, 2012 at 8:50 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> [ new patch ]

Well, I think it's about time to start getting some of this code into
our tree. However, I'm still not confident that the code that
actually runs the triggers is entirely solid, so I decided to rip that
stuff out and commit only the syntax support and documentation
portions of this patch. We can add the actual trigger firing stuff
and PL language support in a subsequent commit or commits. I made a
significant number of modifications.

First, I changed the representation of CreateEventTriggerStmt
considerably, so that we can more easily accommodate multiple filter
variables in future patches without having to whack the code around
too much. I also disentangled the CreateEventTriggerStmt processing
from the event-cache machinery, because it doesn't seem like a good
idea to have evtcache.c and event_trigger.c be deeply intertwined,
from a modularity point of view. I think we might still need to make
a bit more adjustment to the organization of this code - perhaps the
code that is needed by both commands/event_triggers.c and
utils/cache/evtcache.c ought to be moved to something like
catalog/pg_event_trigger.c. However, I haven't done that in this
commit.

Second, I made this work with COMMENT, SECURITY LABEL, and with the
extension mechanism, including updating the documentation.

Third, I also some other documentation updates to match recent changes
and also added the missing documentation for \dy.

Fourth, I rewrote the regression tests fairly extensively to make sure
we're adequately testing all of the syntax that this commit adds: not
only that it works when it's supposed to work, but also that it fails
when it's supposed to fail and emits a hopefully-good error message in
such cases.

And finally there were a bunch of miscellaneous code cleanups (some of
them fixing things that I muffed in earlier incremental patches that I
sent you to merge), and others that touch code you wrote.

I suspect there are probably still a few oversights here, but
hopefully not too many.

The next step here is obviously to complete the work necessary to
actually be able to fire these triggers, as opposed to just saying
that we fire them. I'll write up my thoughts on that topic in a
separate email. I don't think there's a ton of work left to be done
there, but more than zero.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company