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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Daniel Verite <daniel@manitou-mail.org>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-08-07T22:54:43Z
Lists: pgsql-bugs, pgsql-hackers
On Mon, Aug 7, 2017 at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> It has never been the case that there is a guarantee that a new >> operating system environment will have the same or more collations >> available as an earlier version. Even glibc removes or renames locales. A major goal of the BCP 47 language tag format (and related standards) seems to be to decouple technical implementation details (e.g. encoding) from natural language/cultural concerns. That's the only approach that really scales for applications in the modern internet-centric world, I imagine. The glibc collations do very badly there. > Indeed, and one of the alleged selling points of ICU was greater stability > of collation behaviors (including naming). I'd like to try to actually > achieve that. IETF/CLDR describe the naming conventions for locales/collations in excruciating detail, across multiple RFCs/specs. There is no excuse for not making use of that work, IMV. -- 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