| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Andreas Karlsson <andreas(at)proxel(dot)se>, Joe Conway <mail(at)joeconway(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remaining dependency on setlocale() |
| Date: | 2024-08-09 18:24:03 |
| Message-ID: | acd8ab2e5b313e7dd8942cc24eb738950d6589f2.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Fercot | 2024-08-09 18:25:34 | Re: Recovery of .partial WAL segments |
| Previous Message | Nathan Bossart | 2024-08-09 18:17:35 | Re: fix CRC algorithm in WAL reliability docs |