Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ctENX-0006c4-Im for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Mar 2017 14:15:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ctENW-00050f-Km for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Mar 2017 14:15:14 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ctENV-0004zy-Km; Wed, 29 Mar 2017 14:15:13 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ctENS-00035H-GG; Wed, 29 Mar 2017 14:15:12 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v2TEEx0c021748; Wed, 29 Mar 2017 10:14:59 -0400 From: Tom Lane To: Fabien COELHO cc: Corey Huinker , Daniel Verite , "David G. Johnston" , Greg Stark , Erik Rijkers , Robert Haas , Jim Nasby , PostgreSQL , pgsql-hackers-owner@postgresql.org Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) In-reply-to: References: <24980.1490748720@sss.pgh.pa.us> Comments: In-reply-to Fabien COELHO message dated "Wed, 29 Mar 2017 06:18:13 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21746.1490796899.1@sss.pgh.pa.us> Date: Wed, 29 Mar 2017 10:14:59 -0400 Message-ID: <21747.1490796899@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Fabien COELHO writes: >> If we're sufficiently dead set on it, we could go back to the TAP-based >> approach, > Hmmm. You rejected it. I agree that TAP tests are not well suited for some > simple tests because of their initdb overhead. >> but I still doubt that this test is worth the amount of overhead that >> would add. > I think that there is an underlying issue with keeping on rejecting tests > which aim at having a reasonable code coverage of features by exercising > different paths. There's certainly a fair amount of psql behavior that's not adequately testable within the standard regression test infrastructure. Parsing of command line arguments and exit codes for unusual cases both fall into that area, and then there's things like prompts and tab completion. If someone were to put together a TAP test suite that covered all that and made for a meaningful improvement in psql's altogether-miserable code coverage report[1], I would think that that would be a useful expenditure of buildfarm time. What I'm objecting to is paying the overhead for such a suite in order to test just this one thing. I don't think that that passes the bang-for-buck test; or in other words, this isn't the place I would start if I were creating a TAP suite for psql. regards, tom lane [1] https://coverage.postgresql.org/src/bin/psql/index.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers