public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jeff Davis <[email protected]>
To: Peter Eisentraut <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Remaining dependency on setlocale()
Date: Thu, 05 Jun 2025 22:15:34 -0700
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]>
On Tue, 2024-12-17 at 13:14 +0100, Peter Eisentraut wrote:
> > > > +1 to this approach. It makes things more consistent across
> > > > platforms
> > > > and avoids surprising dependencies on the global setting.
> > > >
> >
> > I think this is the best way, and I haven't seen anyone supporting
> > any
> > other idea. (I'm working on those setlocale()-removal patches I
> > mentioned, more very soon...)
>
> I also think this is the right direction, and we'll get closer with
> the
> remaining patches that Thomas has lined up.
>
> I think at this point, we could already remove all locale settings
> related to LC_COLLATE. Nothing uses that anymore.
>
> I think we will need to keep the global LC_CTYPE setting set to
> something useful, for example so that system error messages come out
> in
> the right encoding.
>
> But I'm concerned about the the Perl_setlocale() dance in plperl.c.
> Perl apparently does a setlocale(LC_ALL, "") during startup, and that
> code is a workaround to reset everything back afterwards. We need to
> be
> careful not to break that.
>
> (Perl has fixed that in 5.19, but the fix requires that you set
> another
> environment variable before launching Perl, which you can't do in a
> threaded system, so we'd probably need another fix eventually. See
> <https://github.com/Perl/perl5/issues/8274;.)
To continue this thread, I did a symbol search in the meson build
directory like (patterns.txt attached):
for f in `find . -name *.o`; do
if ( nm --format=just-symbols $f | \
grep -xE -f /tmp/patterns.txt > /dev/null ); then
echo $f; fi; done
and it output:
./contrib/fuzzystrmatch/fuzzystrmatch.so.p/dmetaphone.c.o
./contrib/fuzzystrmatch/fuzzystrmatch.so.p/fuzzystrmatch.c.o
./contrib/isn/isn.so.p/isn.c.o
./contrib/spi/refint.so.p/refint.c.o
./contrib/ltree/ltree.so.p/crc32.c.o
./src/backend/postgres_lib.a.p/commands_copyfromparse.c.o
./src/backend/postgres_lib.a.p/utils_adt_pg_locale_libc.c.o
./src/backend/postgres_lib.a.p/tsearch_wparser_def.c.o
./src/backend/postgres_lib.a.p/parser_scansup.c.o
./src/backend/postgres_lib.a.p/utils_adt_inet_net_pton.c.o
./src/backend/postgres_lib.a.p/tsearch_ts_locale.c.o
./src/bin/psql/psql.p/meson-generated_.._tab-complete.c.o
./src/interfaces/ecpg/preproc/ecpg.p/meson-generated_.._preproc.c.o
./src/interfaces/ecpg/compatlib/libecpg_compat.so.3.18.p/informix.c.o
./src/interfaces/ecpg/compatlib/libecpg_compat.a.p/informix.c.o
./src/port/libpgport_srv.a.p/pgstrcasecmp.c.o
./src/port/libpgport_shlib.a.p/pgstrcasecmp.c.o
./src/port/libpgport.a.p/pgstrcasecmp.c.o
Not a short list, but not a long list, either, so seems tractable. Note
that this misses things like isdigit() which is inlined.
A few observations while spot-checking these files:
---------------------
pgstrcasecmp.c - has code like:
else if (IS_HIGHBIT_SET(ch) && islower(ch))
ch = toupper(ch);
and comments like "Note however that the whole thing is a bit bogus for
multibyte character sets."
Most of the callers are directly comparing with ascii literals, so I'm
not sure what the point is. There are probably some more interesting
callers hidden in there.
----------------------
pg_locale_libc.c -
char2wchar and wchar2char use mbstowcs and wcstombs when the input
locale is NULL. The main culprit seems to be full text search, which
has a bunch of /* TODO */ comments. Another caller is
get_iso_localename().
There are also a couple false positives where mbstowcs_l/wcstombs_l are
emulated with uselocale() and mbstowcs/wcstombs. In that case, it's not
actually sensitive to the global setting.
-----------------------
copyfromparse.c - the input is ASCII so it can use pg_ascii_tolower()
instead of tolower()
-----------------------
Regards,
Jeff Davis
strxfrm
strcoll
wcscoll
wcsxfrm
isw?alpha
isw?digit
isw?alnum
isw?space
isw?upper
isw?lower
tow?upper
tow?lower
isw?graph
isw?punct
isw?cntrl
isw?xdigit
isw?print
wcstombs
mbstowcs
d?n?gettext
bindtextdomain
Attachments:
[text/plain] patterns.txt (208B, ../[email protected]/2-patterns.txt)
download | inline:
strxfrm
strcoll
wcscoll
wcsxfrm
isw?alpha
isw?digit
isw?alnum
isw?space
isw?upper
isw?lower
tow?upper
tow?lower
isw?graph
isw?punct
isw?cntrl
isw?xdigit
isw?print
wcstombs
mbstowcs
d?n?gettext
bindtextdomain
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