Re: [HACKERS] ICU integration - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] ICU integration
Date
Msg-id 48b736bd-e589-6e71-3fd1-2d058c319c66@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] ICU integration  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] ICU integration  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
The v4 patch didn't apply anymore, so here is a rebased patch.  No
changes in functionality.


On 2/16/17 00:10, Peter Eisentraut wrote:
> Updated and rebased patch.
> 
> Significant changes:
> 
> - Changed collversion to type text
> 
> - Changed pg_locale_t to a union
> 
> - Use ucol_getAvailable() instead of uloc_getAvailable(), so the set of
> initial collations is smaller now, because redundancies are eliminated.
> 
> - Added keyword variants to predefined ICU collations (so you get
> "de_phonebook%icu", for example)  (So the initial set of collations is
> bigger now. :) )
> 
> - Predefined ICU collations have a comment now, so \dOS+ is useful.
> 
> - Use ucol_nextSortKeyPart() for abbreviated keys
> 
> - Enhanced tests and documentation
> 
> I believe all issues raised in reviews have been addressed.
> 
> Discussion points:
> 
> - Naming of collations:  Are we happy with the "de%icu" naming?  I might
> have come up with that while reviewing the IPv6 zone index patch. ;-)
> An alternative might be "de$icu" for more Oracle vibe and avoiding the
> need for double quotes in some cases.  (But we have mixed-case names
> like "de_AT%icu", so further changes would be necessary to fully get rid
> of the need for quoting.)  A more radical alternative would be to
> install ICU locales in a different schema and use the search_path, or
> even have a separate search path setting for collations only.  Which
> leads to ...
> 
> - Selecting default collation provider:  Maybe we want a setting, say in
> initdb, to determine which provider's collations get the "good" names?
> Maybe not necessary for this release, but something to think about.
> 
> - Currently (in this patch), we check a collation's version when it is
> first used.  But, say, after pg_upgrade, you might want to check all of
> them right away.  What might be a good interface for that?  (Possibly,
> we only have to check the ones actually in use, and we have dependency
> information for that.)
> 
> 
> 
> 


-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Cost model for parallel CREATE INDEX
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)