On 18 March 2012 22:46, Andrew Dunstan <and...@dunslane.net> wrote: > If you want to generate the tests using some tool, then use whatever works > for you, be it Python or Perl or Valgol, but ideally what is committed (and > this what should be in your patch) will be the SQL output of that, not the > generator plus input.
The reason that I'd prefer to use Perl or even Python to generate pg_regress input, and then have that infrastructure committed is because it's a lot more natural and succint to deal with the problem that way. I would have imagined that a patch that repeats the same boilerplate again and again, to test almost every minor facet of normalisation would be frowned upon. However, if you prefer that, it can easily be accommodated. The best approach might be to commit the output of the Python script as well as the python script itself, with some clean-up work. That way, no one is actually required to run the Python script themselves as part of a standard build, and so they have no basis to complain about additional dependencies. We can run the regression tests from the buildfarm without any additional infrastructure to invoke the python script to generate the pg_regress tests each time. When time comes to change the representation of the query tree, which is not going to be that frequent an event, but will occur every once in a while, the author of the relevant patch should think to add some tests to my existing set, and verify that they pass. That's going to be made a lot easier by having them edit a file that expresses the problem in terms whether two queries should be equivalent or distinct, or what a given query's final canonicalised representation should look like, all with minimal boilerplate. I'm only concerned with making the patch as easy as possible to maintain. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
