From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
cc: David Fetter <david@fetter.org>,
 Arthur Zakirov <a.zakirov@postgrespro.ru>,
        Corey Huinker <corey.huinker@gmail.com>,
        PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH v4] Add \warn to psql
In-reply-to: <alpine.DEB.2.21.1907030842030.17242@lancre>
References: <20190427171548.GM28936@fetter.org>
 <alpine.DEB.2.21.1904272158120.29865@lancre>
 <20190428145813.GO28936@fetter.org>
 <alpine.DEB.2.21.1904282015420.29865@lancre>
 <20190429041106.GB2954@fetter.org>
 <alpine.DEB.2.21.1904290822470.8815@lancre>
 <20190429141710.GD2954@fetter.org>
 <10811be6-cd8d-eadb-9b70-7a6e72ed4ee5@gmail.com>
 <alpine.DEB.2.21.1904301543350.24513@lancre>
 <CAKNkYnz8_wOhuHFp953LEvpsStB9Scyikz4HosSk3Q0w1Fa9Pw@mail.gmail.com>
 <20190501073857.GY28936@fetter.org> <11038.1562098250@sss.pgh.pa.us>
 <alpine.DEB.2.21.1907030842030.17242@lancre>
Comments: In-reply-to Fabien COELHO <coelho@cri.ensmp.fr>
	message dated "Wed, 03 Jul 2019 09:05:28 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31000.1562162768.1@sss.pgh.pa.us>
Date: Wed, 03 Jul 2019 10:06:08 -0400
Message-ID: <31001.1562162768@sss.pgh.pa.us>
Precedence: bulk

Fabien COELHO <coelho@cri.ensmp.fr> writes:
> The point is that there would be at least *one* TAP tests so that many 
> other features of psql, although not all, can be tested. I have been 
> reviewing quite a few patches without tests because of this lack of 
> infrastructure, and no one patch is ever going to justify a TAP test on 
> its own. It has to start somewhere. Currently psql coverage is abysmal, 
> around 40% of lines & functions are called by the whole non regression 
> tests, despite the hundreds of psql-relying tests.

Yeah, but the point I was trying to make is that that's mostly down to
laziness.  I see no reason that we couldn't be covering a lot of these
features in src/test/regress/sql/psql.sql, with far less overhead.
The interactive aspects of psql can't be tested that way ... but since
this patch doesn't actually provide any way to test those, it's not much
of a proof-of-concept.

IOW, the blocking factor here is not "does src/bin/psql/t/ exist",
it's "has somebody written a test that moves the coverage needle
meaningfully".  I'm not big on adding a bunch of overhead first and
just hoping somebody will do something to make it worthwhile later.

			regards, tom lane