Re: [PATCH v4] Add \warn to psql
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Fetter <david@fetter.org>
Cc: Arthur Zakirov <a.zakirov@postgrespro.ru>,
Fabien COELHO <coelho@cri.ensmp.fr>,
Corey Huinker <corey.huinker@gmail.com>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2019-07-02T20:10:50Z
Lists: pgsql-hackers
Attachments
- easier-warn-test.patch (text/x-diff) patch
David Fetter <david@fetter.org> writes: > [ v7-0001-Add-warn-to-psql.patch ] I took a look at this. I have no quibble with the proposed feature, and the implementation is certainly simple enough. But I'm unconvinced about the proposed test scaffolding. Spinning up a new PG instance is a *hell* of a lot of overhead to pay for testing something that could be tested as per attached. Admittedly, the attached doesn't positively prove which pipe each output string went down, but that does not strike me as a concern large enough to justify adding a TAP test for. I'd be happier about adding TAP infrastructure if it looked like it'd be usable to test some of the psql areas that are unreachable by the existing test methodology, particularly tab-complete.c and prompt.c. But I don't see anything here that looks like it'll work for that. I don't like what you did to command_checks_all, either --- it could hardly say "bolted on after the fact" more clearly if you'd written that in <blink><red> text. If we need an input-stream argument, let's just add it in a rational place and adjust the callers. There aren't that many of 'em, nor has the subroutine been around all that long. regards, tom lane
Commits
-
Add \warn command to psql.
- 02e95a5049f7 13.0 landed