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/
