Re: badly calculated width of emoji in psql - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: badly calculated width of emoji in psql
Date
Msg-id CAFj8pRAAJQJZF-gSfwRoryFHsKmxjAc7W1=9hOy-MY23tO1Ong@mail.gmail.com
Whole thread Raw
In response to Re: badly calculated width of emoji in psql  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers


čt 26. 8. 2021 v 17:25 odesílatel Jacob Champion <pchampion@vmware.com> napsal:
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!

Great, thanks

Pavel


--Jacob

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
Next
From: Bruce Momjian
Date:
Subject: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)