Message-ID: <c9c525fff10bbb6c701fa443f096b212a7288ac1.camel@j-davis.com>
Subject: Re: Change initdb default to the builtin collation provider
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers@postgresql.org
Date: Fri, 24 Oct 2025 09:54:45 -0700
In-Reply-To: <aeb851257920a4f79b7a49fc9e1b114f36235296.camel@j-davis.com>
References: <e4ac16908dad3eddd3ed73c4862591375a3f0539.camel@j-davis.com>
	 <cbf88173-fce9-49f1-a9ee-29f8e982b98a@eisentraut.org>
	 <aeb851257920a4f79b7a49fc9e1b114f36235296.camel@j-davis.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/c9c525fff10bbb6c701fa443f096b212a7288ac1.camel%40j-davis.com>
Precedence: bulk

On Fri, 2025-10-17 at 15:02 -0700, Jeff Davis wrote:
> On Fri, 2025-10-17 at 17:23 +0200, Peter Eisentraut wrote:
> > I remain violently opposed to this idea.=C2=A0 I don't understand how i=
t
> > could be acceptable to just not provide a good display order by
> > default=20
> > and have everyone rewrite their queries.
>=20
> I assume that you favor alternative 3 listed here[1], which is to use
> ICU "und" as the default. Is that correct? Or do you prefer to get
> the
> locale from the environment at initdb time?

Right now we're still stuck with the worst possible default: libc. Can
you make a more concrete counter-proposal here that sorts through some
of the details?

* Should we base the ICU locale on the environment, or just default
everyone to the "und" locale?

* If ICU support is disabled, how does that affect the defaults?

* If using the environment, what happens if the locale is not supported
by ICU (in particular "C" or "C.UTF-8")?

* What would be the default encoding, or should that come from the
environment?

* The ICU provider has some weaknesses around non-UTF8 encodings
because of casts from wchar_t and the use of tolower() in
downcase_identifier(). Are those potential blockers, and if so, are
they fixable?

* Can we try harder to find an acceptable way to use memcmp() for the
indexes by default, at least primary keys, even if the database
collation is ICU? I know that I've argued for this in the past and it's
been soundly rejected[1], but some variation on this idea could be
worthy of consideration.

Regards,
	Jeff Davis

[1]
https://www.postgresql.org/message-id/b7a9f32eee8d24518f791168bc6fb653d1f95=
f4d.camel@j-davis.com