> Peter Eisentraut <peter.eisentr...@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
