Re: Remaining dependency on setlocale()

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(dot)camel(at)j-davis(dot)com