On 03/18/2012 07:46 PM, Peter Geoghegan wrote:
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.
If your tests are that voluminous then maybe they are not what we're
looking for anyway. As Tom noted:
IMO the objective of a regression test is not to memorialize every single
case the code author thought about during development. ISTM it would not take
very many cases to have reasonable code coverage.
Why exactly does this feature need particularly to have script-driven
regression test generation when others don't?
If this is a general pattern that people want to follow, then maybe we
need to plan and support it rather than just add a random test
generation script here and there.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
