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

Dilip Kumar <dilipbalaut(at)gmail(dot)com> writes:
> On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin
> <oleksandr(dot)shulgin(at)zalando(dot)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