From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ICU integration |
Date: | 2017-03-09 21:13:20 |
Message-ID: | 48b736bd-e589-6e71-3fd1-2d058c319c66@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
v5-0001-ICU-support.patch | application/x-patch | 153.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-09 21:37:29 | Re: exposing wait events for non-backends (was: Tracking wait event for latches) |
Previous Message | Peter Geoghegan | 2017-03-09 21:11:21 | Re: Cost model for parallel CREATE INDEX |