Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
От | Peter Geoghegan |
---|---|
Тема | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values |
Дата | |
Msg-id | CAH2-WzmA+4Ovi=vFNRet9ap0b+Xb7qm=it1rvPnOdTYANGH1LA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values
Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values |
Список | pgsql-bugs |
On Thu, Aug 17, 2017 at 6:13 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 8/14/17 23:55, Peter Geoghegan wrote: >> pg_import_system_collations() should simply use uloc_countAvailable() >> + uloc_getAvailable, rather than ucol_countAvailable() + >> ucol_getAvailable(). > > It's not clear to me that this is better. Why do we need to use a > function that is clearly not the preferred API for this ("col" vs "loc") > just to get more entries? My argument for doing this is very simple: ICU/CLDR/BCP 47 provides stability guarantees for locales, not collations [1]. For example, as we discussed, de_BE didn't actually go away -- it just stopped being a distinct collation within ICU, for reasons that are implementation defined. I admit that there are arguments against this, but by far the most important consideration should be the stability of the names used for pg_collation entries created during initdb. > If we go down this route, then we'll be on > the hook forever to keep adding more and more predefined entries by > whatever means necessary. Why? Locales have a mapping to various ISO codes (Country, language, etc). It's not like new ones come along very often. [1] https://tools.ietf.org/html/bcp47#section-3.4 -- Peter Geoghegan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: