| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-11-03 21:54:13 |
| Message-ID: | 483b1cde450f44b73ddae9492cec6aae5b7bc112.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2025-11-03 at 11:59 -0800, Jeff Davis wrote:
> Reverting commit 5e6e42e may be the right thing, but I'd like to hear
> what others have to say on this point first. In particualr, I'd like
> to
> know whether such a revert is based on principle, a practical
> problem,
> or just an abundance of caution.
>
> Another option we have here is LC_CTYPE=LC_COLLATE=C for non-libc
> providers, but leave it as in v17 for libc providers. If someone
> explicitly wants libc behavior (by specifying something like "use
> locale" in plperl), they probably want to be using the libc provider
> for the database.
Actually, there's yet another option: lc_ctype and lc_collate could be
GUCs again. If they don't affect any backend behavior, then why not?
The user would have complete control.
(Probably PGC_POSTMASTER, because one of the goals is to not rely on
setlocale() in the backends.)
Of course, we need to be sure that they are compatible with the
database encoding. We have code to do that, but not sure how reliable
it is across platforms.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-11-03 21:55:45 | Re: Use merge-based matching for MCVs in eqjoinsel |
| Previous Message | Joel Jacobson | 2025-11-03 21:45:00 | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |