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

  1. Reject use of ucol_strcollUTF8() before ICU 53

  2. Rethink behavior of pg_import_system_collations().

  3. Faster expression evaluation and targetlist projection.