Re: [HACKERS] Re: ICU collation variant keywords and pg_collationentries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] Re: ICU collation variant keywords and pg_collationentries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values)
Date
Msg-id 20170819231554.GA12816@marmot
Whole thread Raw
In response to Re: [HACKERS] Re: ICU collation variant keywords and pg_collationentries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values)  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Re: ICU collation variant keywords and pg_collationentries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> wrote:
>I think you're contending that, as formulated, this is not a valid v10 open
>item.  Are you?

As the person that came up with this formulation, I'd like to give a
quick summary of my current understanding of the item's status:

* We're in agreement that we ought to have initdb create initial collations based on ICU locales, not based on distinct
ICUcollations [1].
 

* We're in agreement that variant keywords should not be created for each base locale/collation [2].

Once these two changes are made, I think that everything will be in good
shape as far as pg_collation name stability goes. It shouldn't take
Peter E. long to write the patch. I'm happy to write the patch on his
behalf if that saves time.

We're also going to work on the documentation, to make keyword variants
like -emoji and -traditional at least somewhat discoverable, and to
explain the capabilities of custom ICU collations more generally.

[1] https://postgr.es/m/f67f36d7-ceb6-cfbd-28d4-413c6d22fe5b@2ndquadrant.com
[2] https://postgr.es/m/3862d484-f0a5-9eef-c54e-3f6808338726@2ndquadrant.com

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative
Next
From: "MauMau"
Date:
Subject: Re: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?