public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Jeff Davis <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Remaining dependency on setlocale()
Date: Tue, 10 Jun 2025 17:32:01 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CA+hUKGK7qKDHgoh1HuvMhtcpAwwVBA5BDt33vCzYYqCLfQTtzw@mail.gmail.com>
<CA+hUKGLLTy155HTQ6HfHu5-XPNfoFgDsRVUWevj+O6p3UmvPkg@mail.gmail.com>
<[email protected]>
<CA+hUKGL82jG2PdgfQtwWG+_51TQ--6M9XNa3rtt7ub+S3Pmfsw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+hUKGKcS-Zhi8Ud+tv2TanzXBQjH+WsLyPY9DUDXob5VoYAtg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
On 07.06.25 00:23, Jeff Davis wrote:
> On Thu, 2025-06-05 at 22:15 -0700, Jeff Davis wrote:
>> To continue this thread, I did a symbol search in the meson build
>> directory like (patterns.txt attached):
>
> Attached a rough patch series which does what everyone seemed to agree
> on:
>
> * Change some trivial ASCII cases to use pg_ascii_* variants
> * Set LC_COLLATE and LC_CTYPE to C with pg_perm_setlocale
> * Introduce a new global_lc_ctype for callers that still need to use
> operations that depend on datctype
v1-0001-copyfromparse.c-use-pg_ascii_tolower-rather-than-.patch
v1-0002-contrib-spi-refint.c-use-pg_ascii_tolower-instead.patch
v1-0003-isn.c-use-pg_ascii_toupper-instead-of-toupper.patch
v1-0004-inet_net_pton.c-use-pg_ascii_tolower-rather-than-.patch
These look good to me.
v1-0005-Add-global_lc_ctype-to-hold-locale_t-for-datctype.patch
This looks ok (but might depend on how patch 0006 turns out).
v1-0006-Use-global_lc_ctype-for-callers-of-locale-aware-f.patch
I think these need further individual analysis and explanation why these
should use the global lc_ctype setting. For example, you could argue
that the SQL-callable soundex(text) function should use the collation
object of its input value, not the global locale. But furthermore,
soundex_code() could actually just use pg_ascii_toupper() instead. And
in ts_locale.c, the isalnum_l() call should use mylocale that already
exists in that function. The problem to solve it getting a good value
into mylocale. Using the global setting confuses the issue a bit, I think.
v1-0007-Fix-the-last-remaining-callers-relying-on-setloca.patch
Do we have any data what platforms we'd need these checks for?
Also, if you look into wparser_def.c what p_isxdigit is used for, it's
used for parsing XML (presumably HTML) files, so we just need ASCII-only
behavior and no locale dependency.
v1-0008-Set-process-LC_COLLATE-C-and-LC_CTYPE-C.patch
As I mentioned earlier in the thread, I don't think we can do this for
LC_CTYPE, because otherwise system error messages would not come out in
the right encoding. For the LC_COLLATE settings, I think we could just
do the setting in main(), where the other non-database-specific locale
categories are set.
view thread (56+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Remaining dependency on setlocale()
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox