Re: Remaining dependency on setlocale()

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remaining dependency on setlocale()
Date: 2025-07-08 01:14:10
Message-ID: 88a72487b694a2f1e44ca771a6178d07dc00329c.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2025-07-01 at 08:06 -0700, Jeff Davis wrote:
> Attached rebased v3.

And here's v4.

I changed the global variable to only hold the LC_CTYPE (not
LC_COLLATE), because windows doesn't support a _locale_t that
represents multiple categories with different locales.

This patch series is designed to not have any changes in behavior.
There was some feedback that I could go further, but I'll leave those
suggestions for future patches, in case one causes an unexpected
behavior change and needs to be reverted. I intend to start committing
these soon.

v4-0008 uses LC_C_LOCALE, and I'm not sure if that's portable, but if
the buildfarm complains then I'll fix it or revert it.

Regards,
Jeff Davis

Attachment Content-Type Size
v4-0001-Force-LC_COLLATE-to-C-in-postmaster.patch text/x-patch 3.0 KB
v4-0002-Change-wchar2char-and-char2wchar-to-accept-a-loca.patch text/x-patch 6.9 KB
v4-0003-Initialize-datctype-in-global-locale_t-variable.patch text/x-patch 3.7 KB
v4-0004-fuzzystrmatch-use-global_libc_ctype.patch text/x-patch 3.7 KB
v4-0005-ltree-use-global_libc_ctype.patch text/x-patch 748 bytes
v4-0006-Use-global_libc_ctype-for-downcase_identifier-and.patch text/x-patch 2.9 KB
v4-0007-tsearch-use-global_libc_ctype.patch text/x-patch 5.6 KB
v4-0008-No-longer-accept-NULL-for-wchar2char-char2wchar.patch text/x-patch 2.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2025-07-08 01:40:20 Re: Can can I make an injection point wait occur no more than once?
Previous Message Andy Fan 2025-07-08 01:01:52 Re: A assert failure when initdb with track_commit_timestamp=on