Re: Unicode normalization SQL functions

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

In response to

Responses

Browse pgsql-hackers by date

  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