Re: Pre-proposal: unicode normalized text
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Nico Williams <nico@cryptonector.com>
Cc: pgsql-hackers@postgresql.org
Date: 2023-10-03T22:34:44Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Try again to fix the MSVC build
- 151ffcf6d8c1 17.0 landed
-
Additional unicode primitive functions.
- a02b37fc0832 17.0 landed
On Tue, 2023-10-03 at 15:15 -0500, Nico Williams wrote: > Ugh, My client is not displying 'a' correctly Ugh. Is that an argument in favor of normalization or against? I've also noticed that some fonts render the same character a bit differently depending on the constituent code points. For instance, if the accent is its own code point, it seems to be more prominent than if a single code point represents both the base character and the accent. That seems to be a violation, but I can understand why that might be useful. > > Almost every Latin input mode out there produces precomposed > characters > and so they effectively produce NFC. The problem is not the normal case, the problem will be things like obscure input methods, some kind of software that's being too clever, or some kind of malicious user trying to confuse the database. > > That means that indices > need to normalize strings, but tables need to store unnormalized > strings. That's an interesting idea. Would the equality operator normalize first, or are you saying that the index would need to recheck the results? Regards, Jeff Davis