Re: TAP output format in pg_regress - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: TAP output format in pg_regress
Date
Msg-id 5e6bc6a6-0a4e-109d-2b7d-c286dc58d609@enterprisedb.com
Whole thread Raw
In response to Re: TAP output format in pg_regress  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: TAP output format in pg_regress
Re: TAP output format in pg_regress
List 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 by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Improving btree performance through specializing by key shape, take 2
Next
From: Tom Lane
Date:
Subject: Re: TAP output format in pg_regress