From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: Sandro Santilli <strk@kbt.io>, Regina Obe <lr@pcorp.us>,
        pgsql-hackers@lists.postgresql.org, Jeff Davis <pgsql@j-davis.com>
Subject: Re: Order changes in PG16 since ICU introduction
In-reply-to: <533d93c5-f604-8e5f-4a48-975c08c53d59@enterprisedb.com>
References: <000b01d97465$c34bbd60$49e33820$@pcorp.us> <3353947.1682092131@sss.pgh.pa.us> <ZELDOktA75yYG4Z2@hst.kbt.io> <533d93c5-f604-8e5f-4a48-975c08c53d59@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Fri, 21 Apr 2023 19:14:13 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3365332.1682098091.1@sss.pgh.pa.us>
Date: Fri, 21 Apr 2023 13:28:11 -0400
Message-ID: <3365333.1682098091@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3365333.1682098091%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> If the database is created with locale provider ICU, then lc_collate 
> does not apply here, so the result might be correct (depending on what 
> locale you have set).

FWIW, an installation created under LANG=C defaults to ICU locale
en-US-u-va-posix for me (see psql \l), and that still sorts as
expected on my RHEL8 box.  We've not seen buildfarm problems either.

I am wondering however whether this doesn't mean that all our carefully
coded fast paths for C locale just went down the drain.  Does the ICU
code have any of that?  Has any performance testing been done to see
what impact this change had on C-locale installations?  (The current
code coverage report for pg_locale.c is not encouraging.)

			regards, tom lane