Thread

Re: Remaining dependency on setlocale()

Jeff Davis <pgsql@j-davis.com> — 2025-11-29T21:04:00Z

On Thu, 2025-11-27 at 09:08 +0800, Chao Li wrote:
> > On Nov 26, 2025, at 09:50, Chao Li <li.evan.chao@gmail.com> wrote:
> > 
> > I will review the rest 3 commits tomorrow.
> 
> 10 - 0009
> 
> Just curious. As isaplha() and toupper() come from the same header
> file ctype.h, if we replace toupper with pg_ascii_toupper, does
> isapha also need to be handled?

OK.

What do you think about the change overall? Is fuzzystrmatch inherently
ASCII-based? Does it cause behavior changes aside from soundex()? Does
the behavior change in soundex() matter?

> 11 - 0010
> 
> I think assert both dstsize and len are redundant, because
> dstsize=len+1, and no place to change their values.

OK.

What do you think of the change overall?

> 
> If (local == NULL || local->ctype == NULL)
>   Local = libc or other fallback;
> Return default_locale->ctype->strfold_ident(dest, destsize, src,
> srclen, local);
> 
> This way avoids the duplicate code.

OK. The fallback would still be ASCII though, right?

> I just feel the GUC name is very misleading. Without carefully
> reading the doc, users may very easy to consider lc_collate the
> system’s locale. If it only affects extensions, then let’s name it
> accordingly, for example, “extension_lc_collate”, or
> “legacy_lc_collate”.

It is the system locale, it's just that we won't be using the system
locale for most purposes, so it has very little effect: PLs,
extensions, and libraries used by extensions that happen to rely on the
system locale. That is a bit confusing, which is why I previously just
set LC_COLLATE=C. This patch addresses Daniel's concern that people
might still want lc_collate set to something other than C. I'm not sure
we want this patch, it's just a POC.


I didn't attach a new series here yet, but will after some of the
earlier patches get committed.

Regards,
	Jeff Davis