Re: Remaining dependency on setlocale() - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Remaining dependency on setlocale()
Date
Msg-id acd8ab2e5b313e7dd8942cc24eb738950d6589f2.camel@j-davis.com
Whole thread Raw
In response to Re: Remaining dependency on setlocale()  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
On Fri, 2024-08-09 at 13:41 +0200, Andreas Karlsson wrote:
> I am leaning towards that we should write our own pure ascii
> functions
> for this.

That makes sense for a lot of call sites, but it could cause breakage
if we aren't careful.

>  Since we do not support any non-ascii compatible encodings
> anyway I do not see the point in having locale support in most of
> these
> call-sites.

An ascii-compatible encoding just means that the code points in the
ascii range are represented as ascii. I'm not clear on whether code
points in the ascii range can return different results for things like
isspace(), but it sounds plausible -- toupper() can return different
results for 'i' in tr_TR.

Also, what about the values outside 128-255, which are still valid
input to isspace()?

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: fix CRC algorithm in WAL reliability docs
Next
From: Stefan Fercot
Date:
Subject: Re: Recovery of .partial WAL segments