Re: Remaining dependency on setlocale()
Jeff Davis <pgsql@j-davis.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
fuzzystrmatch: use pg_ascii_toupper().
- b96a9fd76f32 19 (unreleased) landed
-
Avoid global LC_CTYPE dependency in pg_locale_icu.c.
- 0a90df58cf38 19 (unreleased) landed
-
downcase_identifier(): use method table from locale provider.
- 87b2968df0f8 19 (unreleased) landed
-
ltree: fix case-insensitive matching.
- 806555e3000d 18.2 landed
- 7f007e4a044a 19 (unreleased) landed
-
Fix multibyte issue in ltree_strncasecmp().
- 898991966bc9 14.21 landed
- 335b2f30b468 15.16 landed
- b80227c0a54c 16.12 landed
- b8cfe9dc2e7f 17.8 landed
- f79e239e0bc6 18.2 landed
- 84d5efa7e3eb 19 (unreleased) landed
-
Use multibyte-aware extraction of pattern prefixes.
- 9c8de1596912 19 (unreleased) landed
-
Add pg_iswcased().
- 630706ced04e 19 (unreleased) landed
-
Remove char_tolower() API.
- 1e493158d3d2 19 (unreleased) landed
-
Make regex "max_chr" depend on encoding, not provider.
- 19b966243c38 19 (unreleased) landed
-
Change some callers to use pg_ascii_toupper().
- 99cd8890beca 19 (unreleased) landed
-
Allow pg_locale_t APIs to work when ctype_is_c.
- 147602822597 19 (unreleased) landed
-
Add #define for UNICODE_CASEMAP_BUFSZ.
- 8d299052fe58 19 (unreleased) landed
-
Inline pg_ascii_tolower() and pg_ascii_toupper().
- ec4997a9d733 19 (unreleased) landed
-
Avoid global LC_CTYPE dependency in pg_locale_libc.c.
- f81bf78ce12b 19 (unreleased) landed
-
Force LC_COLLATE to C in postmaster.
- 5e6e42e44fe1 19 (unreleased) landed
-
Change wchar2char() and char2wchar() to accept a locale_t.
- 53cd0b71ee2e 19 (unreleased) landed
-
Use pg_ascii_tolower()/pg_ascii_toupper() where appropriate.
- d81dcc8d6243 19 (unreleased) landed
-
inet_net_pton.c: use pg_ascii_tolower() rather than tolower().
- 8898082a5d3e 18.0 landed
-
isn.c: use pg_ascii_toupper() instead of toupper().
- 7a6880fadc17 18.0 landed
-
contrib/spi/refint.c: use pg_ascii_tolower() instead.
- 78bd364ee39c 18.0 landed
-
copyfromparse.c: use pg_ascii_tolower() rather than tolower().
- 4c787a24e7e2 18.0 landed
-
Revert "Tidy up locale thread safety in ECPG library."
- 3c8e463b0d88 18.0 cited
-
Tidy up locale thread safety in ECPG library.
- 8e993bff5326 18.0 cited
-
All supported systems have locale_t.
- 8d9a9f034e92 17.0 cited
On Wed, 2024-08-14 at 12:00 -0700, Jeff Davis wrote: > On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote: > > 1. The process global locale is always "C". If you ever call > > uselocale(), it can only be for short stretches, and you have to > > restore it straight after; perhaps it is only ever used in > > replacement > > _l() functions for systems that lack them. You need to use _l() > > functions for all non-"C" locales. The current database default > > needs > > to be available as a variable (in future: thread-local variable, or > > reachable from one), so you can use it in _l() functions. The "C" > > locale can be accessed implicitly with non-l() functions, or you > > could > > ban those to reduce confusion and use foo_l(..., LC_GLOBAL_LOCALE) > > for > > "C". Or a name like PG_C_LOCALE, which, in backend code could be > > just > > LC_GLOBAL_LOCALE, while in frontend/library code it could be the > > singleton mechanism I showed in CF#5166. > > +1 to this approach. It makes things more consistent across platforms > and avoids surprising dependencies on the global setting. > > We'll have to be careful that each call site is either OK with C, or > that it gets changed to an _l() variant. We also have to be careful > about extensions. Did we reach a conclusion here? Any thoughts on moving in this direction, and whether 18 is the right time to do it? Regards, Jeff Davis