| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com>, 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 11:41:26 |
| Message-ID: | fc61c88f-ab78-4870-ada6-e915e9dc7a19@proxel.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/8/24 12:45 AM, Jeff Davis wrote:
> My point was just that there are a lot of those call sites (especially
> for isspace()) in various parsers. It feels like a lot of code churn to
> change all of them, when a lot of them seem to be intended for ascii
> anyway.
>
> And where do we get the locale_t structure from? We can create our own
> at database connection time, and supply it to each of those call sites,
> but I'm not sure that's a huge advantage over just using uselocale().
I am leaning towards that we should write our own pure ascii functions
for this. 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.
Andewas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michail Nikolaev | 2024-08-09 11:45:12 | Re: Conflict detection and logging in logical replication |
| Previous Message | Shlok Kyal | 2024-08-09 11:20:31 | Re: long-standing data loss bug in initial sync of logical replication |