Re: TAP output format in pg_regress

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: TAP output format in pg_regress
Date: 2022-07-04 14:27:20
Message-ID: 5e6bc6a6-0a4e-109d-2b7d-c286dc58d609@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-04 14:39:37 Re: TAP output format in pg_regress
Previous Message Matthias van de Meent 2022-07-04 14:18:35 Re: Improving btree performance through specializing by key shape, take 2