Horton

Re: badly calculated width of emoji in psql

John Naylor <john.naylor@enterprisedb.com>

View thread View on postgr.es
From: John Naylor <john.naylor@enterprisedb.com>
To: Jacob Champion <pchampion@vmware.com>
Cc: "pavel.stehule@gmail.com" <pavel.stehule@gmail.com>, "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>, "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>
Date: 2021-08-12T21:13:31Z
Lists: pgsql-hackers

Attachments

The patch looks pretty good to me. I just have a stylistic suggestion which
I've attached as a text file. There are also some outdated comments that
are not the responsibility of this patch, but I kind of want to fix them
now:

 *  - Hangul Jamo medial vowels and final consonants (U+1160-U+11FF)
 * have a column width of 0.

We got rid of this range in d8594d123c1, which is correct.

 *  - Other format characters (general category code Cf in the Unicode
 * database) and ZERO WIDTH SPACE (U+200B) have a column width of 0.

We don't treat Cf the same as Me or Mn, and I believe that's deliberate. We
also no longer have the exception for zero-width space.

It seems the consensus so far is that performance is not an issue, and I'm
inclined to agree.

I'm a bit concerned about the build dependencies not working right, but
it's not clear it's even due to the patch. I'll spend some time
investigating next week.

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

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