On Thu, 2025-06-05 at 10:53 +0200, Dominique Devienne wrote:
> Thanks Laurenz. Indeed, Using LOCALE vs BUILTIN_LOCALE matters.
>
> On Linux, no error unlike on Windows (still inconsistent there IMHO),
> but the result is slightly different for datcollate and datctype (C vs en_US),
> while the same for datlocprovider and datlocale, what I looked at.
>
> Thus I kinda persist that there *is* a portability issue here.
Perhaps, if omitting BUILTIN_LOCALE actually fails on Windows
(I cannot test it, no Windows nearby).
> Also, note what the doc says:
>
> 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.
You are right, and that's how it works on Linux.
BUILTIN_LOCALE is not required.
> So two issues here.
> 1) the doc is wrong or misleading on this.
Perhaps the problem is in the implementation, not the documentation.
> 2) the same command works on Linux, but not Windows.
Unfortunately I am not in a position to get to the bottom of that.
In principle, it is acceptable for commands to fail on Windows and work
elsewhere, if operating system things like collations are involved.
But I agree that the "builtin" locale provider should work the same everywhere.
Yours,
Laurenz Albe