Re: new environment variable INITDB_LOCALE_PROVIDER - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: new environment variable INITDB_LOCALE_PROVIDER
Date
Msg-id 70b850f2f825df09be3444f76bb80ee10f471690.camel@j-davis.com
Whole thread Raw
In response to Re: new environment variable INITDB_LOCALE_PROVIDER  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: new environment variable INITDB_LOCALE_PROVIDER
List pgsql-hackers
On Fri, 2025-10-10 at 12:13 +0800, Chao Li wrote:
> Are we assuming that 
>
> * if the settings come from command line options, then the user is
> intentionally doing that, so we throw an error
> * if the settings come from env, then the user might not be aware of
> them, so we only issue a warning?
>
> If that’s the case, I’m not fully convinced by this design. Since
> initdb is a one-time operation, I think it would be better to require
> everything to be explicit.

That would have been ideal a long time ago, but plain "initdb" without
locale options has succeeded for a long time, using information from
the environment. If we make that fail and require the user to specify
the options explicitly, I fear that would be too disruptive to the many
scripts around.

So we need to do something reasonable when the provider is builtin and
LC_CTYPE/LC_COLLATE from the environment are incompatible with UTF-8.
Forcing LC_CTYPE=C and/or LC_COLLATE=C:

  * Only happens if:
    - the provider is builtin;
    - LC_CTYPE/LC_COLLATE come from the environment (i.e.
      --locale/--lc-ctype/--lc-collate are unspecified); and
    - LC_CTYPE/LC_COLLATE are incompatible with UTF-8.
  * Has little practical effect because those settings aren't
    used many places when the provider is builtin or ICU.

so I think a warning is acceptable there.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: new environment variable INITDB_LOCALE_PROVIDER
Next
From: Jeff Davis
Date:
Subject: Re: Clarification on Role Access Rights to Table Indexes