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

From Kyotaro Horiguchi
Subject Re: initdb --no-locale=C doesn't work as specified when the environment is not C
Date
Msg-id 20231127.120042.1919434306028321316.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: initdb --no-locale=C doesn't work as specified when the environment is not C  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: initdb --no-locale=C doesn't work as specified when the environment is not C
List pgsql-hackers
At Wed, 22 Nov 2023 11:04:01 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > Commit 3e51b278db leaves lc_* conf lines as commented-out when
> > their value is "C". This leads to the following behavior.
> 
> Hmm ... I see a contributing factor here: this bit in
> postgresql.conf.sample is a lie:
> 
> #lc_messages = 'C'            # locale for system error message
>                     # strings
> 
> A look in guc_tables.c shows that the actual default is '' (empty
> string), which means "use the environment", and that matches how the
> variable is documented in config.sgml.  Somebody --- quite possibly me
> --- was misled by the contents of postgresql.conf.sample into thinking
> that the lc_xxx GUCs all default to C, when that's only true for the
> others.

It seems somewhat intentional that only lc_messages references the
environment at boot time. On the other hand, previously, in the
absence of a specified locale, initdb would embed the environmental
value in the configuration file, as it seems to be documented. Given
that initdb is always used for cluster creation, it's unlikey that
systems depend on this boot-time default for their operation.

> I think that a more correct fix for this would treat lc_messages
> differently from the other lc_xxx GUCs.  Maybe just eliminate the
> hack about not substituting "C" for that one?

For example, the --no-locale option for initdb is supposed to set all
categories to 'C'. That approach would lead to the postgres
referencing the runtime environment for all categories except
lc_messages, which I believe contradicts the documentation. In my
biew, if lc_messages is exempted from that hack, then all other
categories should be similarly excluded as in the second approach
among the attached in the previous mail.

> In any case, we need to fix this mistake in postgresql.conf.sample.

If you are not particularly concerned about the presence of quotation
marks, I think it would be fine to go with the second approach and
make the necessary modification to the configuration file accordingly.

With the attached patch, initdb --no-locale generates the following
lines in the configuration file.

> lc_messages = C                # locale for system error message
>                     # strings
> lc_monetary = C                # locale for monetary formatting
> lc_numeric = C                # locale for number formatting
> lc_time = C                # locale for time formatting

By the way, the lines around lc_* in the sample file seem to have
somewhat inconsistent indentations. Wouldnt' it be preferable to fix
this? (The attached doesn't that.)


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: New instability in stats regression test
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] fix race condition in libpq (related to ssl connections)