Thread: [COMMITTERS] pgsql: Standardize describe.c's behavior for no-matching-objects abit
[COMMITTERS] pgsql: Standardize describe.c's behavior for no-matching-objects abit
From
Tom Lane
Date:
Standardize describe.c's behavior for no-matching-objects a bit more. 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/77cb4a1d6730a69906baf0b052aae7dc11f07764 Modified Files -------------- src/bin/psql/describe.c | 69 +++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 58 insertions(+), 11 deletions(-)