Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On 03/18/2012 07:46 PM, Peter Geoghegan wrote:
> On 18 March 2012 22:46, Andrew Dunstan<andrew(at)dunslane(dot)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