Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Daniel Verite <daniel@manitou-mail.org>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-08-14T16:51:34Z
Lists: pgsql-bugs, pgsql-hackers
On Mon, Aug 14, 2017 at 9:27 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: >> I can't understand why that should be. ICU 58 uses CLDR 30, which >> quite clearer does have the locale de_BE: > > I'm not familiar with the nuances of CLDR, but quite plausibly there is > a *locale* named de_BE, but the collation of "de" as used in "BE" is not > different than "de" used elsewhere, so it is omitted from the list as > redundant. That's also what I think is the most likely explanation. Maybe the lesson here is that we ought to be adding all locales at initdb time, not all distinct collations. That would also get us a dozen or so identical English variants, and so on, just like with glibc. I don't especially want that, but it seems like it might be better from a stability point of view. After all, CLDR gives guarantees about the stability of locales, not collations. -- Peter Geoghegan
Commits
-
Reject use of ucol_strcollUTF8() before ICU 53
- d6391b03b302 10.0 landed
-
Rethink behavior of pg_import_system_collations().
- 0b13b2a7712b 10.0 cited
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited