> On Oct 11, 2025, at 02:28, Jeff Davis wrote:
>
> 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
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 warnin
On Tue, 2025-10-14 at 21:51 +0200, Peter Eisentraut wrote:
> I'm skeptical that we want user-facing environment variables to
> provide
> initdb defaults. The use for that hasn't really been explained.
One motivation was to make it smoother to change the initdb default
provider:
https://www.post
On Fri, 2025-10-10 at 11:32 +0200, Peter Eisentraut wrote:
> > * Use environment variable name PG_LOCALE_PROVIDER, which seems
> > more
> > consistent.
>
> Is this not something that could already be done using
> PG_TEST_INITDB_EXTRA_OPTS ?
1. PG_LOCALE_PROVIDER is a documented user-facing option
Am 09.10.2025 um 06:27 schrieb Jeff Davis :
>
> On Tue, 2025-07-29 at 16:55 -0700, Jeff Davis wrote:
>> $SUBJECT makes it easier to test other providers, especially the
>> regression tests.
>
> Rebased.
>
> Changes:
>
> * Use environment variable name PG_LOCALE_PROVIDER, which seems more
> con
On Tue, 2025-07-29 at 16:55 -0700, Jeff Davis wrote:
> $SUBJECT makes it easier to test other providers, especially the
> regression tests.
Rebased.
Changes:
* Use environment variable name PG_LOCALE_PROVIDER, which seems more
consistent.
* Updated doc.
* If the provider is builtin and the LC_
> On Oct 11, 2025, at 10:06, Jeff Davis wrote:
>
> On Sat, 2025-10-11 at 08:30 +0800, Chao Li wrote:
>> * If we make that fail, I don’t think that would break existing
>> scripts. Because the default provider is libc and you are introducing
>> a new environment variable to set locale provider,
On Fri, 2025-10-17 at 17:04 +0200, Peter Eisentraut wrote:
> But that patch adds a nontrivial amount of new logic and contains no
> documentation, and some of the additional information is spread over
> other threads, so I don't have the whole picture.
That logic is there because there are still
> On Oct 9, 2025, at 12:27, Jeff Davis wrote:
>
> * If the provider is builtin and the LC_CTYPE or LC_COLLATE environment
> variables aren't compatible with UTF-8, it can override those to "C".
> But if --locale, --lc-ctype, or --lc-collate are specified and
> incompatible, they will throw an e
On 14.10.25 22:45, Jeff Davis wrote:
If you think we can change the initdb default without introducing an
environment variable, then perhaps we don't need v3-0002. What do you
think about v3-0001?
I think in general it could make sense to do something like
+#define DEFAULT_BUILTIN_LOCALE
On 10.10.25 20:09, Jeff Davis wrote:
On Fri, 2025-10-10 at 11:32 +0200, Peter Eisentraut wrote:
* Use environment variable name PG_LOCALE_PROVIDER, which seems
more
consistent.
Is this not something that could already be done using
PG_TEST_INITDB_EXTRA_OPTS ?
1. PG_LOCALE_PROVIDER is a docum
On Sat, 2025-10-11 at 08:30 +0800, Chao Li wrote:
> * If we make that fail, I don’t think that would break existing
> scripts. Because the default provider is libc and you are introducing
> a new environment variable to set locale provider, thus a plain
> initdb will not use builtin provider. Maybe
From e5876ac466d5158d3aafa1cf92dc54ff45a6b996 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Thu, 17 Jul 2025 13:07:50 -0700
Subject: [PATCH v1] initdb: new environment variable INITDB_LOCALE_PROVIDER
Controls the locale provider used by initdb.
Also specifies defaults for both the builtin pr
13 matches
Mail list logo
