> 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
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