On Wed, Jul 18, 2012 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
I have committed code to do this. It's basically similar to what you
had before, but I reworked the event cache machinery heavily. I think
that the new organization will be easier to extent to meet future
needs, and it also gets rid of a lot of boilerplate code whose job was
to translate between different representations. I also committed the
PL/pgsql support code, but not the code for the other PLs. It should
be easy to rebase that work and resubmit it as a separate patch,
though, or maybe one patch per PL would be better.
Obviously, there's quite a bit more work that could be done here --
passing more context, add more firing points, etc. -- but now we've at
least got the basics.
As previously threatened, I amended this code so that triggers fire
once per DDL command. So internally generated command nodes that are
used as an argument-passing mechanism do not fire triggers, for
example. I believe this is the right decision because I think, as I
mentioned in another email to Tom yesterday, that generating and
passing around command tags is a really bad practice that we should be
looking to eliminate, not institutionalize. It posed a major obstacle
to my 9.2-era efforts to clean up the behavior of our DDL under
concurrency, for example.
I think, however, that it would be useful to have an event trigger
that is defined to fire "every time a certain type of SQL object gets
created" rather than "every time a certain command gets executed".
That could complement, not replace, this mechanism.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
