Re: badly calculated width of emoji in psql

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: badly calculated width of emoji in psql
Дата
Msg-id fa68be752004b6d05fc72bac0d7c489f4abba4b3.camel@vmware.com
обсуждение исходный текст
Ответ на Re: badly calculated width of emoji in psql  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: badly calculated width of emoji in psql  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Wed, 2021-08-25 at 16:15 -0400, John Naylor wrote:
> On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion <pchampion@vmware.com> wrote:
> >
> > Does there need to be any sanity check for overlapping ranges between
> > the combining and fullwidth sets? The Unicode data on a dev's machine
> > would have to be broken somehow for that to happen, but it could
> > potentially go undetected for a while if it did.
> 
> It turns out I should have done that to begin with. In the Unicode
> data, it apparently happens that a character can be both combining
> and wide, and that will cause ranges to overlap in my scheme:

I was looking for overlaps in my review, but I skipped right over that,
sorry...

On Thu, 2021-08-26 at 11:12 -0400, John Naylor wrote:
> I pushed Jacob's patch with the addendum I shared upthread, plus a
> comment about search order. I also took the liberty of changing the
> author in the CF app to Jacob. Later I'll push detecting non-spacing
> characters beyond the BMP.

Thanks!

--Jacob

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
Следующее
От: vignesh C
Дата:
Сообщение: Re: Logical replication - schema change not invalidating the relation cache