Re: Update Unicode data to Unicode 16.0.0
От | Peter Eisentraut |
---|---|
Тема | Re: Update Unicode data to Unicode 16.0.0 |
Дата | |
Msg-id | 224411f3-5f98-4bf5-a831-569b2a30a392@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Update Unicode data to Unicode 16.0.0 (Jeremy Schneider <schneider@ardentperf.com>) |
Ответы |
Re: Update Unicode data to Unicode 16.0.0
|
Список | pgsql-hackers |
On 15.03.25 07:54, Jeremy Schneider wrote: > in favor of leaving it alone because ICU is there for when I need > up-to-date unicode versions. > > From my perspective, the whole point of the builtin collation was to > one option that avoids these problems that come with updating both ICU > and glibc. > > So I guess the main point of the builtin provider just that it's faster > than ICU? A mistake that some people apparently continue to make in this discussion is that they assume that the only thing the Unicode tables drive is the builtin collation provider. This is not true, the Unicode tables were there long before the builtin collation provider, and they have other purposes. And we knew at the time the builtin collation provider was added that it would have certain problems with the Unicode table updates, and we accepted it with the understanding that this would not change our procedures. Otherwise, we would likely not have accepted it in its current form. Those who are now trying to make the builtin collation provider have properties that it does not have and was not intended to have when it was added, they would need to arrange the work to make it have those properties if they want them, rather than insist that progress in other areas must stop because they are content with the current state.
В списке pgsql-hackers по дате отправления: