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". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
