On Sat, 2025-12-13 at 17:48 +0800, Chao Li wrote:
> 1 - 0001
> ```
> + int match_mblen pg_attribute_unused();
> ```
>
> Why this variable is marked unused? It’s actually used.
Fixed and committed.
I originally marked it unused because I just had an:
Assert(match[match_mblen] == '\0');
but I changed it to just set it:
match[match_mblen] = '\0';
for clarity, even though I think the underlying API guarantees NUL-
termination.
> 2 - 0002
>
> I did a search and found one place that you missed at line 181 in
> pg_locale.h
> ```
> extern bool char_is_cased(char ch, pg_locale_t locale);
> ```
Thank you, fixed and committed.
I'll continue committing v12 0003-0005. Note that I'm planning to
backport 0003.
I'm also inclined to move forward with 0006. It's not a long-term
solution, but it solves an instance of the problem under discussion in
this thread (removes setlocale() dependency) and is a narrow fix.
After that, remaining loose ends:
* 0007: Can we just rip out the non-ASCII support? If it's gone all
this time without UTF8 support, and there's no suggestion about what
the non-ASCII behavior should be (in docs or source code), then it's
probably not terribly important.
* Use of pg_strncasecmp() in the backend, which uses tolower() to do
case-insensitive matching of command options, e.g. "if
(pg_strcasecmp(a, "plain") == 0)" to check for PLAIN storage in CREATE
TYPE.
* strerror(): either consider an lc_ctype GUC, or the approach over
here[1].
* Daniel suggests that we need some way to set LC_COLLATE for
extensions/dependencies.
* address calls to pg_tolower in datetime.c and tzparser.c -- can those
just be pg_ascii_tolower()?
* examine remaining isalpha(), etc., calls in the backend
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/flat/90f176c5b85b9da26a3265b2630ece3552068566.camel@j-davis.com
