Re: Add CREATE support to event triggers

On 10 January 2014 23:22, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:

> On the subject of testing the triggers, Robert Haas 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.

Yes, all we are doing is firing a trigger that has access to the
information about the current object.

> A couple of very hand-wavy ideas:
>
> 1. in the event trigger, DROP the original object and CREATE it as
> reported by the creation_commands SRF.
>
> 2. Have ddl_command_start open a savepoint, and then roll it back in
> ddl_command_end, then create the object again. Not sure this is doable
> because of the whole SPI nesting issue .. maybe with C-language event
> trigger functions?

We need to be clear what action we are testing exactly. Once we know
that we can come up with a test mechanism.

We can come up with various tests that test coverage but that may not
be enough. Mostly we're just splitting up fields from the DDL, like
object name into its own text field, as well as augmenting it with
database name. That's pretty simple and shouldn't require much
testing. This code seems likely to be prone to missing features much
more so than actual bugs. Missing a piece of useful information in the
JSON doesn't mean there is a bug.

If all the event trigger does is generate JSON, then all we need to do
is test that the trigger fired and generated well-formed JSON with the
right information content. That should be very simple and I would say
the simpler the better.
To do that we can run code to parse the JSON and produce formatted
text output like this...
Field | Value
---------+-----------
XX afagaha
YY aamnamna
The output can be derived from visual inspection, proving that we
generated the required JSON.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services