On Fri, 2023-03-10 at 07:48 -0800, Jeff Davis wrote:
> On Fri, 2023-03-10 at 15:48 +0100, Peter Eisentraut wrote:
> > Yes, of course. So we can't really do what I was thinking of.
>
> OK, I plan to commit something like the patch in this thread soon. I
> just need to add an explanatory comment.
On Fri, 2023-03-10 at 15:48 +0100, Peter Eisentraut wrote:
> Yes, of course. So we can't really do what I was thinking of.
OK, I plan to commit something like the patch in this thread soon. I
just need to add an explanatory comment.
It passes CI, but it's possible that there could be more buildf
On 10.03.23 15:38, Jeff Davis wrote:
On Fri, 2023-03-10 at 10:59 +0100, Peter Eisentraut wrote:
I think originally the locale forced the encoding. With ICU, we have
a
choice. We could either stick to the encoding suggested by the OS,
or
pick our own.
We still need LC_COLLATE and LC_CTYPE to
On Fri, 2023-03-10 at 10:59 +0100, Peter Eisentraut wrote:
> I think originally the locale forced the encoding. With ICU, we have
> a
> choice. We could either stick to the encoding suggested by the OS,
> or
> pick our own.
We still need LC_COLLATE and LC_CTYPE to match the database encoding
t
On 10.03.23 03:26, Jeff Davis wrote:
That's because ICU always uses UTF-8 by default. ICU works just fine
with many other encodings; is there a reason it doesn't take it from
the environment just like for provider=libc?
I think originally the locale forced the encoding. With ICU, we have a
ch
