pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Chao Li <li.evan.chao@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Remaining dependency on setlocale()
Date: Tue, 16 Dec 2025 09:32:09 +0800
Message-ID: <651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com> (raw)
In-Reply-To: <5f70ee8a3f73df753285f8928c01dd32f14d7fcb.camel@j-davis.com>
References: <4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel@j-davis.com>
	<a8666c391dfcabe79868d95f7160eac533ace718.camel@j-davis.com>
	<6956823dd669abc64183fc91e64dc2e56e31f3ea.camel@j-davis.com>
	<ed394f839d813762ddcd65cfcab0e062f8b5e0b1.camel@j-davis.com>
	<CA+hUKGLYcbnHBXhHk_OFwZ03LE+D=cAirm7TVN8fMhT9rgcTbA@mail.gmail.com>
	<f040113cf384ada69558ec004a04a3ddb3e40a26.camel@j-davis.com>
	<CA+hUKGJxSDFcTZSGi++PTC=jM49q1oK=v7Lcdf96VQXXvLhoow@mail.gmail.com>
	<cdd20efc0f5418c597791a1e3a5abb68fa3ce35b.camel@j-davis.com>
	<d9657a6e51aa20702447bb2386b32fea6218670f.camel@j-davis.com>
	<b1ea6756-279a-4924-9146-e125af2057b2@eisentraut.org>
	<8186b28a1a39e61a0d833a4c25a8909ebbbabd48.camel@j-davis.com>
	<450ceb6260cad30d7afdf155d991a9caafee7c0d.camel@j-davis.com>
	<DDD50039-02B4-4033-8D22-B086BC448E1C@gmail.com>
	<78edc741a168c54d57cc898a5877b6443527a2c8.camel@j-davis.com>
	<83F6E6A9-FF29-41C9-9E15-EA5360E912D0@gmail.com>
	<5f65b85740197ba6249ea507cddf609f84a6188b.camel@j-davis.com>
	<38f3f4a6-e95e-47a7-914f-110dd6191301@eisentraut.org>
	<0e186a9a92634f0c5675a618ff5685d00cd8f836.camel@j-davis.com>
	<0E8DD47F-710D-45E1-B87F-2336042A377E@gmail.com>
	<5f70ee8a3f73df753285f8928c01dd32f14d7fcb.camel@j-davis.com>



> On Dec 16, 2025, at 03:34, Jeff Davis <pgsql@j-davis.com> wrote:
> 
> On Sat, 2025-12-13 at 17:48 +0800, Chao Li wrote:
>> 1 - 0001
>> ```
>> + int match_mblen pg_attribute_unused();
>> ```
>> 
>> Why this variable is marked unused? It’s actually used.
> 
> Fixed and committed.
> 
> I originally marked it unused because I just had an:
> 
>   Assert(match[match_mblen] == '\0');
> 
> but I changed it to just set it:
> 
>   match[match_mblen] = '\0';
> 
> for clarity, even though I think the underlying API guarantees NUL-
> termination.
> 
>> 2 - 0002
>> 
>> I did a search and found one place that you missed at line 181 in
>> pg_locale.h
>> ```
>> extern bool char_is_cased(char ch, pg_locale_t locale);
>> ```
> 
> Thank you, fixed and committed.
> 
> 
> I'll continue committing v12 0003-0005. Note that I'm planning to
> backport 0003.

I have re-reviewed 0003-0005 last week, they all look good to me.

I have no comment on backport 0003.

> 
> I'm also inclined to move forward with 0006. It's not a long-term
> solution, but it solves an instance of the problem under discussion in
> this thread (removes setlocale() dependency) and is a narrow fix.
> 
> 
> After that, remaining loose ends:
> 
> * 0007: Can we just rip out the non-ASCII support? If it's gone all
> this time without UTF8 support, and there's no suggestion about what
> the non-ASCII behavior should be (in docs or source code), then it's
> probably not terribly important.
> 
> * Use of pg_strncasecmp() in the backend, which uses tolower() to do
> case-insensitive matching of command options, e.g. "if
> (pg_strcasecmp(a, "plain") == 0)" to check for PLAIN storage in CREATE
> TYPE.
> 
> * strerror(): either consider an lc_ctype GUC, or the approach over
> here[1].
> 
> * Daniel suggests that we need some way to set LC_COLLATE for
> extensions/dependencies.
> 
> * address calls to pg_tolower in datetime.c and tzparser.c -- can those
> just be pg_ascii_tolower()?
> 
> * examine remaining isalpha(), etc., calls in the backend
> 
> Regards,
> Jeff Davis
> 
> [1]
> https://www.postgresql.org/message-id/flat/90f176c5b85b9da26a3265b2630ece3552068566.camel@j-davis.co...
> 

I just reviewed 0006-0007. Only got one comment on 0006:

```
@@ -306,6 +342,7 @@ create_pg_locale_icu(Oid collid, MemoryContext context)
 	result = MemoryContextAllocZero(context, sizeof(struct pg_locale_struct));
 	result->icu.locale = MemoryContextStrdup(context, iculocstr);
 	result->icu.ucol = collator;
+	result->icu.lt = loc;
```

The old code didn’t create a locale object and store in result, thus it didn’t have a logic to free the created locale. This patch now dose that, but I don’t see where the created locale object is free-ed. I suppose newlocale() will allocate memory from the OS, so I guess the memory should be free-ed somewhere.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/









view thread (96+ messages)  latest in thread

Message-ID: <651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com>
Permalink:  ../651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com/
Also on:    postgresql.org/message-id/651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com

 · 

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: pgsql-hackers@postgresql.org
  Cc: li.evan.chao@gmail.com, pgsql@j-davis.com, peter@eisentraut.org, thomas.munro@gmail.com, tgl@sss.pgh.pa.us
  Subject: Re: Remaining dependency on setlocale()
  In-Reply-To: <651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox