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

From John Naylor
Subject Re: badly calculated width of emoji in psql
Date
Msg-id CAFBsxsGZKnT12qO_R3-6Owi7ARZP-88e13jDdgXXaS3y+RkE0Q@mail.gmail.com
Whole thread Raw
In response to Re: badly calculated width of emoji in psql  (Jacob Champion <pchampion@vmware.com>)
Responses Re: badly calculated width of emoji in psql
List pgsql-hackers

On Mon, Aug 16, 2021 at 1:04 PM Jacob Champion <pchampion@vmware.com> wrote:
>
> On Mon, 2021-08-16 at 11:24 -0400, John Naylor wrote:
> >
> > On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > > How large do libpgcommon deliverables get with this patch?  Skimming
> > > through the patch, that just looks like a couple of bytes, still.
> >
> > More like a couple thousand bytes. That's because the width
> > of mbinterval doubled. If this is not desirable, we could teach the
> > scripts to adjust the width of the interval type depending on the
> > largest character they saw.
>
> True. Note that the combining character table currently excludes
> codepoints outside of the BMP, so if someone wants combinations in
> higher planes to be handled correctly in the future, the mbinterval for
> that table may have to be widened anyway.

Hmm, somehow it escaped my attention that the combining character table script explicitly excludes those. There's no comment about it. Maybe best to ask Peter E. (CC'd)

Peter, does the combining char table exclude values > 0xFFFF for size reasons, correctness, or some other consideration?

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: when the startup process doesn't (logging startup delays)
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Reducing memory consumption for pending inval messages