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

From Jacob Champion
Subject Re: badly calculated width of emoji in psql
Date
Msg-id fa68be752004b6d05fc72bac0d7c489f4abba4b3.camel@vmware.com
Whole thread Raw
In response to Re: badly calculated width of emoji in psql  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: badly calculated width of emoji in psql  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 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: vignesh C
Date:
Subject: Re: Logical replication - schema change not invalidating the relation cache