Re: CREATE DATABASE command for non-libc providers

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

In response to

Browse pgsql-hackers by date

  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