Re: encoding affects ICU regex character classification

Поиск
Список
Период
Сортировка
От Jeremy Schneider
Тема Re: encoding affects ICU regex character classification
Дата
Msg-id 1b6fa4be-fdac-481e-82f5-1ffdfbbdb0fd@ardentperf.com
обсуждение исходный текст
Ответ на Re: encoding affects ICU regex character classification  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: encoding affects ICU regex character classification  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On 12/12/23 1:39 PM, Jeff Davis wrote:
> On Sun, 2023-12-10 at 10:39 +1300, Thomas Munro wrote:
>> Unless you also
>> implement built-in case mapping, you'd still have to call libc or ICU
>> for that, right?
> 
> We can do built-in case mapping, see:
> 
> https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel@j-davis.com
> 
>>   It seems a bit strange to use different systems for
>> classification and mapping.  If you do implement mapping too, you
>> have
>> to decide if you believe it is language-dependent or not, I think?
> 
> A complete solution would need to do the language-dependent case
> mapping. But that seems to only be 3 locales ("az", "lt", and "tr"),
> and only a handful of mapping changes, so we can handle that with the
> builtin provider as well.

This thread has me second-guessing the reply I just sent on the other
thread.

Is someone able to test out upper & lower functions on U+A7BA ... U+A7BF
across a few libs/versions?  Theoretically the upper/lower behavior
should change in ICU between Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
(specifically in ICU 64 / Unicode 12).  And I have no idea if or when
glibc might have picked up the new unicode characters.

-Jeremy


-- 
http://about.me/jeremy_schneider




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: encoding affects ICU regex character classification
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Clean up find_typedefs and add support for Mac