Re: [PATCH v4] Add \warn to psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: David Fetter <david(at)fetter(dot)org>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v4] Add \warn to psql
Date: 2019-07-03 14:06:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Liudmila Mantrova 2019-07-03 14:27:51 Re: SQL/JSON path issues/questions
Previous Message Tom Lane 2019-07-03 13:53:14 Re: Where is SSPI auth username determined for TAP tests?