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
