| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remaining dependency on setlocale() |
| Date: | 2025-10-31 19:59:20 |
| Message-ID: | 09ca947879d178f35d6765c70095733810a4c3c0.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2025-10-31 at 10:40 +0100, Peter Eisentraut wrote:
> But I'm not sure that we actually want to make that switch. It would
> be
> good if our code is independent of the global locale settings, but
> that
> doesn't mean that there couldn't be code in extensions, other
> libraries,
> or other corners of the operating system that relies on this.
This question has been brewing for a while. How should we make this
decision?
> In
> general, and I haven't looked this up in the applicable standards, it
> seems like a good idea to accurately declare what encoding you
> operate in.
One frustration (for me, at least) is that there is no way to set the
encoding without specifying the locale. LC_CTYPE=C.UTF-8 is close, but
the libc version is not available on all platforms and has some quirks.
That makes any changes to the initdb default logic difficult to sort
out. Some combinations which seem simple -- like ICU/UTF8 -- need to
handle the case when LC_CTYPE is not compatible with UTF-8, even though
the LC_CTYPE has no effect in that case.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2025-10-31 20:03:14 | Re: POC: Parallel processing of indexes in autovacuum |
| Previous Message | Tom Lane | 2025-10-31 19:48:14 | Re: contrib/sepgsql regression tests have been broken for months |