On Tue, Dec 9, 2025, at 11:00 PM, Chao Li wrote: > Now “show log_min_messages” prints the raw string the user set, in > above example, there is not a white-space between the two log levels, > and “show” result doesn’t have a white-space between the two log levels > either. IMO, “SHOW log_min_messages” should display a stable result, in > other words, say “fatal, backend:log” and “backend:log, fatal” should > show the same result as they are actually meaning the same. So, I would > suggest normalize the raw string: put the general level in the first > place and sort others by process type, then SHOW returns the normalized > string. >
I thought about it but leave it alone because (a) it would increase this patch footprint and (b) the input might be different from the output. I could also be done in another patch but under reflection an unstable output can break tests or whatever uses the SHOW log_min_messages output. I thought this change would require a new show_log_min_messages to manipulate the input again but we can reassign the GUC value after sorting the existing list and creating a new string list. > In the “if” and “else” clauses, there are duplicate code to valid log > levels. We should refactor the code to avoid the duplication. For > example, pull up “loglevel” to the “for” loop level, then we can valid > it after the “if-else”. > The for loop is duplicate but if you create a separate function for it but the result is: src/backend/commands/variable.c | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) I'll post a patch in a couple of hours after spend more time in it. -- Euler Taveira EDB https://www.enterprisedb.com/
