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

  1. Reject use of ucol_strcollUTF8() before ICU 53

  2. Rethink behavior of pg_import_system_collations().

  3. Faster expression evaluation and targetlist projection.