Re: Order changes in PG16 since ICU introduction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Order changes in PG16 since ICU introduction
Date
Msg-id 3365333.1682098091@sss.pgh.pa.us
Whole thread Raw
In response to Re: Order changes in PG16 since ICU introduction  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses RE: Order changes in PG16 since ICU introduction
Re: Order changes in PG16 since ICU introduction
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Order changes in PG16 since ICU introduction
Next
From: Tom Lane
Date:
Subject: Re: LLVM strip -x fails