Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q6WRv-00068P-Dv for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jun 2023 13:10:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q6WRu-0007Py-Bh for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jun 2023 13:10:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q6WRu-0007Pp-1u for pgsql-hackers@lists.postgresql.org; Tue, 06 Jun 2023 13:10:10 +0000 Received: from mail.verite.pro ([185.16.44.216]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q6WRq-000XBM-RP for pgsql-hackers@lists.postgresql.org; Tue, 06 Jun 2023 13:10:08 +0000 Received: by mail.verite.pro (Postfix, from userid 1000) id 4692A8C01E4; Tue, 6 Jun 2023 15:10:04 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: Order changes in PG16 since ICU introduction From: "Daniel Verite" To: "Jeff Davis" Cc: Peter Eisentraut , Andrew Gierth , Tom Lane , pgsql-hackers@lists.postgresql.org In-Reply-To: <5111ffef640ec7ed5b75d9791dd18d821e96c31e.camel@j-davis.com> Date: Tue, 06 Jun 2023 15:09:59 +0200 Message-Id: <45f0cd77-9c85-4c5e-9396-adbccdb635e2@manitou-mail.org> X-Mailer: Manitou v1.7.3 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jeff Davis wrote: > New patch series attached. I plan to commit 0001 and 0002 soon, unless > there are objections. >=20 > 0001 causes the "C" and "POSIX" locales to be treated with > memcmp/pg_ascii semantics in ICU, just like in libc. We also > considered a new "none" provider, but it's more invasive, and we can > always reconsider that in the v17 cycle. FWIW I don't quite see how 0001 improve things or what problem it's trying to solve. 0001 creates exceptions throughout the code so that when an ICU collation has a locale name "C" or "POSIX" then it does not behave like an ICU collation, even though pg_collation.collprovider=3D'i' To me it's neither desirable nor necessary that a collation that has collprovider=3D'i' is diverted to non-ICU semantics. Also in the current state, this diversion does not apply to initdb. "initdb --icu-locale=3DC" with 0001 applied reports this: Using language tag "en-US-u-va-posix" for ICU locale "C". The database cluster will be initialized with this locale configuration: provider: icu ICU locale: en-US-u-va-posix LC_COLLATE: fr_FR.UTF-8 [...] and "initdb --locale=3DC" reports this: Using default ICU locale "fr_FR". Using language tag "fr-FR" for ICU locale "fr_FR". The database cluster will be initialized with this locale configuration: provider: icu ICU locale: fr-FR LC_COLLATE: C [...] Could you elaborate a bit more on what 0001 is meant to achieve, from the point of view of the user? Best regards, --=20 Daniel V=E9rit=E9 https://postgresql.verite.pro/ Twitter: @DanielVerite