Re: TAP output format in pg_regress

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: TAP output format in pg_regress
Дата
Msg-id 5e6bc6a6-0a4e-109d-2b7d-c286dc58d609@enterprisedb.com
обсуждение исходный текст
Ответ на Re: TAP output format in pg_regress  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: TAP output format in pg_regress  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: TAP output format in pg_regress  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On 29.06.22 21:50, Daniel Gustafsson wrote:
> Attached is a new version of this patch, which completes the TAP output format
> option such that all codepaths emitting output are TAP compliant.  The verbose
> option is fixed to to not output extraneous newlines which the previous PoC
> did.  The output it made to conform to the original TAP spec since v13/14 TAP
> parsers seem less common than those that can handle the original spec.  Support
> for the new format additions should be quite simple to add should we want that.
> 
> Running pg_regress --verbose should give the current format output.
> 
> I did end up combining TAP and --verbose into a single patch, as the TAP format
> sort of depends on the verbose flag as TAP has no verbose mode.  I can split it
> into two separate should a reviewer prefer that.

I'm not sure what to make of all these options.  I think providing a TAP 
output for pg_regress is a good idea.  But then do we still need the old 
output?  Is it worth maintaining two output formats that display exactly 
the same thing in slightly different ways?

What is the purpose of the --verbose option?  When and how is one 
supposed to activate that?  The proposed default format now hides the 
fact that some tests are started in parallel.  I remember the last time 
I wanted to tweak the output of the parallel tests, people were very 
attached to the particular timing and spacing of the current output.  So 
I'm not sure people will like this.

The timing output is very popular.  Where is that in the TAP output?

More generally, what do you envision we do with this feature?  Who is it 
for, what are the tradeoffs, etc.?




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

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: Improving btree performance through specializing by key shape, take 2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: TAP output format in pg_regress