Re: Add CREATE support to event triggers

On 1/14/14, 2:05 PM, Robert Haas wrote:
> 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".

Can't we capture the JSON, use that to create a new database, and then test against that? Unfortunately it'd be easiest to do that at a high level and not for individual commands, but it's a lot better than nothing...
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net