From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | "Andreas Karlsson" <andreas(at)proxel(dot)se>,"pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unicode normalization SQL functions |
Date: | 2020-02-17 19:14:03 |
Message-ID: | dd16d2c4-e7cb-4e6d-a92d-40e8dc1cf8a6@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
One nitpick:
Around this hunk:
- * unicode_normalize_kc - Normalize a Unicode string to NFKC form.
+ * unicode_normalize - Normalize a Unicode string to the specified form.
*
* The input is a 0-terminated array of codepoints.
*
@@ -304,8 +306,10 @@ decompose_code(pg_wchar code, pg_wchar **result, int
*current)
* string is palloc'd instead, and OOM is reported with ereport().
*/
The comment in full says:
/*
* unicode_normalize - Normalize a Unicode string to the specified form.
*
* The input is a 0-terminated array of codepoints.
*
* In frontend, returns a 0-terminated array of codepoints, allocated with
* malloc. Or NULL if we run out of memory. In frontend, the returned
* string is palloc'd instead, and OOM is reported with ereport().
*/
It looks like the 2nd occurrence of "frontend" was meant to be "backend".
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Mercha | 2020-02-17 20:24:43 | SPI Concurrency Precautions? |
Previous Message | Daniel Verite | 2020-02-17 19:08:00 | Re: Unicode normalization SQL functions |