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@2ndquadrant.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
todo that at a high level and not for individual commands, but it's a lot better than nothing...
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net