Re: LOCALE C.UTF-8 on EDB Windows v17 server - Mailing list pgsql-general

From Laurenz Albe
Subject Re: LOCALE C.UTF-8 on EDB Windows v17 server
Date
Msg-id 271a4c5ac6e568fe9ff250d9e0e70fb13a7eb103.camel@cybertec.at
Whole thread Raw
In response to Re: LOCALE C.UTF-8 on EDB Windows v17 server  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: LOCALE C.UTF-8 on EDB Windows v17 server
List pgsql-general
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



pgsql-general by date:

Previous
From: Dominique Devienne
Date:
Subject: Re: LOCALE C.UTF-8 on EDB Windows v17 server
Next
From: Dominique Devienne
Date:
Subject: Re: LOCALE C.UTF-8 on EDB Windows v17 server