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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: initdb --no-locale=C doesn't work as specified when the environment is not C
Date: 2023-11-22 16:04:01
Message-ID: 1696010.1700669041@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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.

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?

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

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2023-11-22 16:18:32 How to stop autovacuum silently
Previous Message Ashutosh Bapat 2023-11-22 15:53:21 Re: Adding facility for injection points (or probe points?) for more advanced tests