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 CAFBsxsFQ=scF=hgvrUWwDBzf1ZSkdmq1XRN4NJPMtniqNfpBCQ@mail.gmail.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  (Jacob Champion <pchampion@vmware.com>)
Re: badly calculated width of emoji in psql  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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.

--
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Default to TIMESTAMP WITH TIME ZONE?
Next
From: Thomas Munro
Date:
Subject: Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?