RE: Order changes in PG16 since ICU introduction

> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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

Just another metric.

On my mingw64 setup, I built a test database on PG16 (built with icu
support) and PG15 (no icu support)

CREATE DATABASE test TEMPLATE=template0 ENCODING = 'UTF8' LC_COLLATE = 'C'
LC_CTYPE = 'C';

I think the above is the similar setup we have when testing.

On PG15

SELECT '+' < '-' ; returns true

On PG 16 returns false

For PG 16, to strk's point, you have to do: to get a true
SELECT '+' COLLATE "C" < '-' COLLATE "C";

I would expect since I'm initializing my db in collate C they would both
behave the same