From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CREATE DATABASE command for non-libc providers |
Date: | 2025-06-06 22:47:16 |
Message-ID: | b098d11a5b18090279102062a6418453ce49c7ef.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2025-06-06 at 22:03 +0200, Daniel Verite wrote:
> +1 for the patch
Thank you, committed.
>
> Here we let 'locale' or 'lc_collate/lc_ctype' which is the same
> thing,
> defaulting from the template database.
Right, in the normal case it's OK, but if anything goes wrong, it gets
fairly confusing.
> > * Force the environment variables LC_COLLATE=C and LC_CTYPE=C
> > unconditionally, and pg_perm_setlocale() them
>
> Currently that would be a regression for some people, because
> when LC_CTYPE=C, the FTS parser produces substandard results with
> characters beyond ASCII.
In the other thread, I posted a patch:
https://www.postgresql.org/message-id/a1396f17f462ee6561820f755caaf2d12eb9fd15.camel%40j-davis.com
for the callers that rely on datctype (regardless of datlocprovider),
they access the locale_t through a global, and use the "_l" variants.
There should be no behavior change, and we still need to set LC_CTYPE,
so you are right that it's not a solution yet. I think it moves us in
the right direction, though.
If nothing else, we can easily identify the places that have behavior
dependent on datctype, and I could have offered a more clear reply to
the user.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-06-06 22:58:02 | Re: Batch TIDs lookup in ambulkdelete |
Previous Message | Jelte Fennema-Nio | 2025-06-06 22:41:23 | Re: md5 password deprecation might cause problems with PgBouncer setups |