Horton

Re: badly calculated width of emoji in psql

Jacob Champion <pchampion@vmware.com>

View thread View on postgr.es
From: Jacob Champion <pchampion@vmware.com>
To: "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, "michael@paquier.xyz" <michael@paquier.xyz>
Cc: "pavel.stehule@gmail.com" <pavel.stehule@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>
Date: 2021-07-21T16:05:11Z
Lists: pgsql-hackers 
On Wed, 2021-07-21 at 00:08 +0000, Jacob Champion wrote:
> On Mon, 2021-07-19 at 13:13 +0200, Laurenz Albe wrote:
> > That could be adapted; the question is if the approach as such is
> > desirable or not.  This is necessarily a moving target, at the rate
> > that emojis are created and added to Unicode.
> 
> Sure. We already have code in the tree that deals with that moving
> target, though, by parsing apart pieces of the Unicode database. So the
> added maintenance cost should be pretty low.

(I am working on such a patch today and will report back.)

--Jacob

Commits

  1. Extend collection of Unicode combining characters to beyond the BMP

  2. Update display widths as part of updating Unicode

  3. Revert "Rename unicode_combining_table to unicode_width_table"

  4. Change mbbisearch to return the character range