Re: Event Triggers reduced, v1

On 20 July 2012 16:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jul 18, 2012 at 10:22 AM, Robert Haas <robertmhaas(at)gmail(dot)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.

I've just run my own set of tests against these changes, which tests
every supported DDL command (with the exception of "CREATE USER
MAPPING", "ALTER USER MAPPING", "DROP USER MAPPING", "CREATE LANGUAGE"
and "DROP LANGUAGE"), and many variants of each command, and
everything behaves exactly as expected. :)

--
Thom