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-05 16:48:10 |
Message-ID: | 28340.1562345290@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> 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'm fairly suspicious of using TAP tests just to get a regexp match.
The thing I don't like about TAP tests for this is that they won't
notice if the test case prints extra stuff beyond what you were
expecting --- at least, not without care that I don't think we usually
take.
I've thought for some time that we should steal an idea from MySQL
and extend pg_regress so that individual lines of an expected-file
could have regexp match patterns rather than being just exact matches.
I'm not really sure how to do that without reimplementing diff(1)
for ourselves :-(, but that would be a very large step forward if
we could find a reasonable implementation.
Anyway, my opinion about having TAP test(s) for psql remains that
it'll be a good idea as soon as somebody submits a test that adds
a meaningful amount of code coverage that way (and the coverage
can't be gotten more simply). But we don't need a patch that is
just trying to get the camel's nose under the tent.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2019-07-05 16:48:29 | Re: range_agg |
Previous Message | Alexey Bashtanov | 2019-07-05 16:40:49 | Re: log bind parameter values on error |