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-Wz=LyEY4JhaJdBcnUBXu-NO57ki+tZm-_qpTV60Cp9BKvw@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
|
Список | pgsql-bugs |
On Fri, Aug 18, 2017 at 7:47 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 8/17/17 21:22, Peter Geoghegan wrote: >>> 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. > > One argument I can think of is that it is confusing right now. Why is > there de-AT but no de-DE? I know why, but users in "DE" might not and > would be really confused. So I concede that adding the full set would > be useful. Actually, there would be a de-DE. Just like with de-BE, that's ensured by using locales rather than collations. See my self-contained test program, or even the output I posted earlier. -- 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 по дате отправления: