Re: Add CREATE support to event triggers

On Fri, Jan 10, 2014 at 6:22 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>> Here's one idea: create a contrib module that (somehow, via APIs to be
>> invented) runs every DDL command that gets executed through the
>> deparsing code, and then parses the result and executes *that* instead
>> of the original command. Then, add a build target that runs the
>> regression test suite in that mode, and get the buildfarm configured
>> to run that build target regularly on at least some machines. That
>> way, adding syntax to the regular regression test suite also serves to
>> test that the deparsing logic for that syntax is working. If we do
>> this, there's still some maintenance burden associated with having DDL
>> deparsing code, but at least our chances of noticing when we've failed
>> to maintain it should be pretty good.
>
> I gave this some more thought and hit a snag. The problem here is that
> by the time the event trigger runs, the original object has already been
> created. At that point, we can't simply replace the created objects
> with objects that would hypothetically be created by a command trigger.

Hmm, so these triggers are firing after the corresponding actions have
been performed. Yeah, that's tricky. I don't immediately have an
idea how to come up with a comprehensive test framework for that,
although I do think that the way you're structuring the JSON blobs
makes this a whole lot less error-prone than the approaches that have
been explored previously. The big question in my mind is still "if
somebody updates the grammar in gram.y, how do we make sure that they
notice that this stuff needs to be updated to match?". Ideally the
answer is "if they don't, the regression tests fail".

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