Re: [HACKERS] ICU integration
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] ICU integration |
Дата | |
Msg-id | 48b736bd-e589-6e71-3fd1-2d058c319c66@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] ICU integration (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] ICU integration
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: