On 1/14/14, 2:05 PM, Robert Haas wrote:
On Fri, Jan 10, 2014 at 6:22 PM, Alvaro Herrera
<alvhe...@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 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 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
