Re: [PATCH v4] Add \warn to psql

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:29:23
Message-ID: alpine.DEB.2.21.1907031618140.16913@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Tom,

>> 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. [...]
>
> Yeah, but the point I was trying to make is that that's mostly down to
> laziness.

Not always.

I agree that using TAP test if another simpler option is available is not
a good move.

However, in the current state, as soon as there is some variation a test
is removed and coverage is lost, but they could be kept if the check could
be against a regexp.

> 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.

The PoC is checking against a set of regexp instead of expecting an exact
output. Ok, it does not solve all possible test scenarii, that is life.

> 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.

I do intend to add coverage once a psql TAP test is available, as I have
done with pgbench. Ok, some of the changes are still in the long CF queue,
but at least pgbench coverage is around 90%.

I also intend to direct submitted patches to use the TAP infra when
appropriate, instead of "no tests, too bad".

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-07-03 15:04:59 Re: Increasing default value for effective_io_concurrency?
Previous Message Liudmila Mantrova 2019-07-03 14:27:51 Re: SQL/JSON path issues/questions