On Thu, 2025-06-05 at 10:53 +0200, Dominique Devienne wrote:
> If locale_provider is builtin, then locale or builtin_locale must be
> specified and set to either C or C.UTF-8.
>
> It clearly says "locale or builtin_locale", emphasis on the OR.
>
> So two issues here.
> 1) the doc is wrong or misleading on this.
The code in dbcommands.c:createdb():
if (localeEl && localeEl->arg)
{
dbcollate = defGetString(localeEl);
dbctype = defGetString(localeEl);
dblocale = defGetString(localeEl);
}
if (builtinlocaleEl && builtinlocaleEl->arg)
dblocale = defGetString(builtinlocaleEl);
if (collateEl && collateEl->arg)
dbcollate = defGetString(collateEl);
if (ctypeEl && ctypeEl->arg)
dbctype = defGetString(ctypeEl);
if (iculocaleEl && iculocaleEl->arg)
dblocale = defGetString(iculocaleEl);
So LC_COLLATE, LC_CTYPE, and BUILTIN_LOCALE all fall back to LOCALE if
they aren't set. On windows, it fails because LC_COLLATE and LC_CTYPE
fall back to LOCALE, which is "C.UTF-8", which doesn't exist.
(I know the CREATE DATABASE command is confusing, but it grew
historically and we needed to support previously-working commands.)
If you have specific doc suggestions to clarify this, please let me
know.
> 2) the same command works on Linux, but not Windows.
As long as we accept the libc provider, or allow the user to set
LC_COLLATE/LC_CTYPE, then there will be some commands that succeed on
some platforms and fail on others. Even with ICU, there may be versions
that accept a locale and versions that don't.
I'd like to make libc less "special" so that users who don't want to
use it aren't confronted with errors about things that don't matter to
them. I welcome suggestions that can move us closer to that goal
without breaking previously-working commands.
Regards,
Jeff Davis
