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 1nMcL3-0000Ta-Ry for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Feb 2022 21:04:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nMcL1-0005vm-Fw for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Feb 2022 21:04:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nMcL1-0005vc-6i for pgsql-hackers@lists.postgresql.org; Tue, 22 Feb 2022 21:04:47 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nMcKx-0007WX-91 for pgsql-hackers@lists.postgresql.org; Tue, 22 Feb 2022 21:04:46 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 5BCD42EA1753 for ; Tue, 22 Feb 2022 22:04:39 +0100 (CET) Received: from s899.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 4CF322E2905E; Tue, 22 Feb 2022 22:04:39 +0100 (CET) Received: from s470.loopia.se (unknown [172.22.191.6]) by s899.loopia.se (Postfix) with ESMTP id 4A5B72C99943; Tue, 22 Feb 2022 22:04:39 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from s630.loopia.se ([172.22.191.6]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with LMTP id rIKxS7U6KL2o; Tue, 22 Feb 2022 22:04:38 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.193 Received: from [192.168.72.144] (customer-89-255-232-193.stosn.net [89.255.232.193]) (Authenticated sender: daniel@yesql.se) by s630.loopia.se (Postfix) with ESMTPSA id 8866C13ACE01; Tue, 22 Feb 2022 22:04:38 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: TAP output format in pg_regress From: Daniel Gustafsson In-Reply-To: <20220222171331.l2glftezpcq5wnei@alap3.anarazel.de> Date: Tue, 22 Feb 2022 22:04:38 +0100 Cc: PostgreSQL Developers Content-Transfer-Encoding: quoted-printable Message-Id: <021DF900-D87B-4AD9-82E1-4BF3EFF4E300@yesql.se> References: <49A54862-C682-4B60-9155-05F178FA79DC@yesql.se> <20220222171331.l2glftezpcq5wnei@alap3.anarazel.de> To: Andres Freund X-Mailer: Apple Mail (2.3608.120.23.2.7) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 22 Feb 2022, at 18:13, Andres Freund wrote: > On 2022-02-22 15:10:11 +0100, Daniel Gustafsson wrote: >> The errorpaths that exit(2) the testrun should be converted to "bail = out" lines >> when running with TAP output, but apart from that I think it's fairly = spec >> compliant. >=20 > I'd much rather not use BAIL - I haven't gotten around to doing = anything about > it, but I really want to get rid of nearly all our uses of bail: Point. We already error out on stderr in pg_regress so we could = probably make die() equivalent output to keep the TAP parsing consistent. At any = rate, awaiting the conclusions on the bail thread and simply (for some value = of) replicating that in this patch is probably the best option? -- Daniel Gustafsson https://vmware.com/