From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: new environment variable INITDB_LOCALE_PROVIDER |
Date: | 2025-10-10 18:28:42 |
Message-ID: | 70b850f2f825df09be3444f76bb80ee10f471690.camel@j-davis.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2025-10-10 18:31:03 | Re: Clarification on Role Access Rights to Table Indexes |
Previous Message | Jeff Davis | 2025-10-10 18:09:35 | Re: new environment variable INITDB_LOCALE_PROVIDER |