Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

Dilip Kumar <dilipbalaut@gmail.com> writes:
> On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin
> <oleksandr.shulgin@zalando.de> wrote:
>> I think can be helpful, though rarely, to be able to send the output of \d*
>> commands to a file.  At the same time it would be nice to see the message on
>> stderr instead of appending to the output file, in case the relation was not
>> found, because of less head-scratching needed to realize the problem.  So
>> I'd vote for changing \dt (and alike) behavior to use stderr.

> +1

> And, we can also change the error message to be more consistent.
> \d says "Did not find any relation named "xxx" ". whereas \dt says "No
> matching relations found".

So, if we're getting into enforcing consistency in describe.c, there's
lots to do.

* listDbRoleSettings does this for a server too old to have the desired
feature:
    fprintf(pset.queryFout,    _("No per-database role settings support in this server version.\n"));

Just about every other function handles too-old-server like this:
    psql_error("The server (version %s) does not support full text search.\n",

* listTables and listDbRoleSettings do this for zero matches:
if (PQntuples(res) == 0 && !pset.quiet){    if (pattern)        fprintf(pset.queryFout, _("No matching relations
found.\n"));   else        fprintf(pset.queryFout, _("No relations found.\n"));}else    ... print the result normally 

Note the test on quiet mode, as well as the choice of two messages
depending on whether the command had a pattern argument or not.

Other functions in describe.c mostly follow this pattern:
if (PQntuples(res) == 0){    if (!pset.quiet)        psql_error("Did not find any relation named \"%s\".\n",
      pattern);    PQclear(res);    return false;} 

So this has a different behavior in quiet mode, which is to print
*nothing* to queryFout rather than a result table with zero entries.
That's probably bogus.  It will also crash, on some machines, if pattern
is NULL, although no doubt nobody's noticed because there would always be
a match.  (One call site does defend itself against null pattern, and it
uses two messages like the previous example.)

So we've got at least three things to normalize:

* fprintf(pset.queryFout) vs. psql_error()

* message wording inconsistencies

* behavior with -q and no matches.

Anybody want to draft a patch?
        regards, tom lane