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-parsed commands in order somewhere.
Dump those commands into a brand new database and use that for testing.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
