On Thu, Jul 12, 2012 at 8:50 AM, Dimitri Fontaine <dimi...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
