Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8NEn-0001K4-VF for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Jul 2022 14:39:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o8NEm-0006Yl-R9 for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Jul 2022 14:39:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8NEm-0006Yc-I7 for pgsql-hackers@lists.postgresql.org; Mon, 04 Jul 2022 14:39:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8NEk-0004W4-9u for pgsql-hackers@lists.postgresql.org; Mon, 04 Jul 2022 14:39:43 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 264EdbvM1558374; Mon, 4 Jul 2022 10:39:37 -0400 From: Tom Lane To: Peter Eisentraut cc: Daniel Gustafsson , Andres Freund , PostgreSQL Developers Subject: Re: TAP output format in pg_regress In-reply-to: <5e6bc6a6-0a4e-109d-2b7d-c286dc58d609@enterprisedb.com> References: <49A54862-C682-4B60-9155-05F178FA79DC@yesql.se> <20220321234924.kcc3q26o7sx6rnfa@alap3.anarazel.de> <489D2B5A-B26F-4918-BC07-B426329169E3@yesql.se> <5e6bc6a6-0a4e-109d-2b7d-c286dc58d609@enterprisedb.com> Comments: In-reply-to Peter Eisentraut message dated "Mon, 04 Jul 2022 16:27:20 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1558372.1656945577.1@sss.pgh.pa.us> Date: Mon, 04 Jul 2022 10:39:37 -0400 Message-ID: <1558373.1656945577@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > 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? Probably is, because this is bad: > ... 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. and so is this: > The timing output is very popular. Where is that in the TAP output? Both of those things are fairly critical for test development. You need to know what else might be running in parallel with a test case, and you need to know whether you just bloated the runtime unreasonably. More generally, I'm unhappy about the proposal that TAP should become the default output. There is nothing particularly human-friendly about it, whereas the existing format is something we have tuned to our liking over literally decades. I don't mind if there's a way to get TAP when you're actually intending to feed it into a TAP-parsing tool, but I am not a TAP-parsing tool and I don't see why I should have to put up with it. regards, tom lane