Re: badly calculated width of emoji in psql

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>

To: John Naylor <john.naylor@enterprisedb.com>, Jacob Champion <pchampion@vmware.com>

Cc: "michael@paquier.xyz" <michael@paquier.xyz>, "pavel.stehule@gmail.com" <pavel.stehule@gmail.com>, "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>

Date: 2021-08-19T18:12:10Z

Lists: pgsql-hackers

On 16.08.21 22:06, John Naylor wrote:
> Peter, does the combining char table exclude values > 0xFFFF for size 
> reasons, correctness, or some other consideration?

I don't remember a reason, other than perhaps making the generated table 
match the previous manual table in scope.  IIRC, the previous table was 
ancient, so perhaps from the days before higher Unicode values were 
universally supported in the code.

Commits

Extend collection of Unicode combining characters to beyond the BMP
- 5bc429aacb37 15.0 landed
Update display widths as part of updating Unicode
- bab982161e05 15.0 landed
Revert "Rename unicode_combining_table to unicode_width_table"
- 1563ecbc1be8 15.0 landed
Change mbbisearch to return the character range
- 78ab944cd4b9 15.0 landed