On 1/10/14, 5:22 PM, Alvaro Herrera 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.
>
> 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?
What if we don't try and do this all in one shot? I'm thinking let the original DDL do it's thing while capturing the
re-parsedcommands in order somewhere. Dump those commands into a brand new database and use that for testing.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net