Dilip Kumar <dilipbal...@gmail.com> writes:
> On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin
> <oleksandr.shul...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
