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 1o8N32-0000nZ-0w for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Jul 2022 14:27:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o8N2z-0006yV-N8 for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Jul 2022 14:27:33 +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 1o8N2y-0006yL-Lm for pgsql-hackers@lists.postgresql.org; Mon, 04 Jul 2022 14:27:33 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8N2p-0004Qd-OA for pgsql-hackers@lists.postgresql.org; Mon, 04 Jul 2022 14:27:29 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7E6DE5C00C4; Mon, 4 Jul 2022 10:27:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 04 Jul 2022 10:27:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1656944842; x= 1657031242; bh=FL6YGEbEbVVR/8/SCDOT2vziQ7Tt4xqUzPgTzyV1yB8=; b=l PUIMKiTgZsFRWIXBfgiwj//Yga9daHGQJdeku4JZ/tu4+WR9AhS45E6TewzQclKY /9T0vETdEBEEjS3LoJg2fVmNSeKkx9eUIAGQkn15TlB9e8tfDFGGOLaYcuWDC3Xn L3LGYyQOFRViMZCBxSHQ7vqhARHZOxIDWmgso9diJFWDzrRxaFvNx2MNf5IDOmh0 rAEdjl5IfyevI42nOEZOBTA6pMSpmJtIIr0juObCabD3iDwKsAZXyXIV4ar37Yka txclD+SYPcrzYhGLLpJgjT6virYyST+1vLjphwhKi8GIGz94/RD1JXS9EOa9JnHh fJhwdLn01KCqQ5wP5lA+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudehledgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnth gvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeehleffgeegudejteei hfelteduvdeifffhffdvjedvffegjeekudeludehudeifeenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghu thesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 4 Jul 2022 10:27:21 -0400 (EDT) Message-ID: <5e6bc6a6-0a4e-109d-2b7d-c286dc58d609@enterprisedb.com> Date: Mon, 4 Jul 2022 16:27:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: TAP output format in pg_regress Content-Language: en-US To: Daniel Gustafsson , Andres Freund Cc: PostgreSQL Developers References: <49A54862-C682-4B60-9155-05F178FA79DC@yesql.se> <20220321234924.kcc3q26o7sx6rnfa@alap3.anarazel.de> <489D2B5A-B26F-4918-BC07-B426329169E3@yesql.se> From: Peter Eisentraut In-Reply-To: <489D2B5A-B26F-4918-BC07-B426329169E3@yesql.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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.?