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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Дата
Msg-id 4F667984.3030307@dunslane.net
обсуждение исходный текст
Ответ на Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)  (Peter Geoghegan <peter@2ndquadrant.com>)
Ответы Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Список pgsql-hackers

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)