• Tom Lane's avatar
    Standardize describe.c's behavior for no-matching-objects a bit more. · 77cb4a1d
    Tom Lane authored
    Most functions in this file are content to print an empty table if there
    are no matching objects.  In some, the behavior is to loop over all
    matching objects and print a table for each one; therefore, without any
    extra logic, nothing at all would be printed if no objects match.
    We accept that outcome in QUIET mode, but in normal mode it seems better
    to print a helpful message.  The new \dRp+ command had not gotten that
    memo; fix it.
    
    listDbRoleSettings() is out of step on this, but I think it's better for
    it to print a custom message rather than an empty table, because of the
    possibility that the user is confused about what the pattern arguments mean
    or which is which.  The original message wording was entirely useless for
    clarifying that, though, not to mention being unlike the wordings used
    elsewhere.  Improve the text, and also print the messages with psql_error
    as is the general custom here.
    
    listTables() is also out in left field, but since it's such a heavily
    used function, I'm hesitant to change its behavior so much as to print
    an empty table rather than a custom message.  People are probably used
    to getting a message.  But we can make the wording more standardized and
    helpful, and print it with psql_error rather than printing to stdout.
    
    In both listDbRoleSettings and listTables, we play dumb and emit an
    empty table, not a custom message, in QUIET mode.  That was true before
    and I see no need to change it.
    
    Several of the places printing such messages risked dumping core if
    no pattern string had been provided; make them more wary.  (This case
    is presently unreachable in describeTableDetails; but it shouldn't be
    assuming that command.c will never pass it a null.  The text search
    functions would only reach the case if a database contained no text
    search objects, which is also currently impossible since we pin the
    built-in objects, but again it seems unwise to assume that here.)
    
    Daniel Gustafsson, tweaked a bit by me
    
    Discussion: https://postgr.es/m/3641F19B-336A-431A-86CE-A80562505C5E@yesql.se
    77cb4a1d
describe.c 152 KB