initdb --no-locale=C doesn't work as specified when the environment is not C - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject initdb --no-locale=C doesn't work as specified when the environment is not C
Date
Msg-id 20231122.162700.1995154567625541112.horikyota.ntt@gmail.com
Whole thread Raw
Responses Re: initdb --no-locale=C doesn't work as specified when the environment is not C
List pgsql-hackers
Commit 3e51b278db leaves lc_* conf lines as commented-out when
their value is "C". This leads to the following behavior.

$ echo LANG
ja_JP.UTF8
$ initdb --no-locale hoge
$ grep lc_ hoge/postgresql.conf
#lc_messages = 'C'                      # locale for system error message
#lc_monetary = 'C'                      # locale for monetary formatting
#lc_numeric = 'C'                       # locale for number formatting
#lc_time = 'C'                          # locale for time formatting

In this scenario, the postmaster ends up emitting log massages in
Japanese, which contradicts the documentation.

https://www.postgresql.org/docs/devel/app-initdb.html

> --locale=locale 
>   Sets the default locale for the database cluster. If this option is
>   not specified, the locale is inherited from the environment that
>   initdb runs in. Locale support is described in Section 24.1.
> 
..
> --lc-messages=locale
>   Like --locale, but only sets the locale in the specified category.

Here's a somewhat amusing case:

$ echo LANG
ja_JP.UTF8
$ initdb --lc_messages=C
$ grep lc_ hoge/postgresql.conf 
#lc_messages = 'C'                      # locale for system error message
lc_monetary = 'ja_JP.UTF8'              # locale for monetary formatting
lc_numeric = 'ja_JP.UTF8'               # locale for number formatting
lc_time = 'ja_JP.UTF8'                  # locale for time formatting

Hmm. it seems that initdb replaces the values of all categories
*except the specified one*. This behavior seems incorrect to
me. initdb should replace the value when explicitly specified in the
command line. If you use -c lc_messages=C, it does perform the
expected behavior to some extent, but I believe this is a separate
matter.

I have doubts about not replacing these lines for purely cosmetic
reasons. In this mail, I've attached three possible solutions for the
original issue: the first one enforces replacement only when specified
on the command line, the second one simply always performs
replacement, and the last one addresses the concern about the absence
of quotes around "C" by allowing explicit specification. (FWIW, I
prefer the last one.)

What do you think about these?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: Change GUC hashtable to use simplehash?
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Make mesage at end-of-recovery less scary.