On 28.03.25 09:13, Peter Eisentraut wrote:
About patch 0003:
I had previously pointed out that the canonicalization might have
been intentional, and that we have canonicalization of ICU locale
names. But we don't have to keep the setlocale()-based locale
checking implementation just for that,
On 31.03.25 15:52, Tom Lane wrote:
Peter Eisentraut writes:
I'm not sure what to do with this. If setlocale() and newlocale()
indeed behave differently in what set of locale names they accept, then
technically we ought to test both of them, since we do use both of them
later on. Or maybe we p
Peter Eisentraut writes:
> I'm not sure what to do with this. If setlocale() and newlocale()
> indeed behave differently in what set of locale names they accept, then
> technically we ought to test both of them, since we do use both of them
> later on. Or maybe we push on with the effort to g
Hi,
On 2025-03-28 09:13:54 +0100, Peter Eisentraut wrote:
> On 27.03.25 11:16, Peter Eisentraut wrote:
> > > Patch 0002 also looks okay, except that the error handling could be
> > > unified with existing code, as I had previously pointed out. Patch
> > > 0005 fixes that.
> >
> > I plan to commi
On 27.03.25 11:16, Peter Eisentraut wrote:
Patch 0002 also looks okay, except that the error handling could be
unified with existing code, as I had previously pointed out. Patch
0005 fixes that.
I plan to commit this one next, after the above had a bit of time to stew.
also done
About pat
On 14.02.25 15:13, Peter Eisentraut wrote:
On 09.02.25 15:52, Peter Eisentraut wrote:
This patch set is still desirable. Here is a rebased version of the
v5 patches. I haven't applied any corrections or review comments.
Here is the same patch set with some review comments.
Patch 0001 looks
On 09.02.25 15:52, Peter Eisentraut wrote:
This patch set is still desirable. Here is a rebased version of the v5
patches. I haven't applied any corrections or review comments.
Here is the same patch set with some review comments.
Patch 0001 looks okay to me. I'm just offering some cosmetic
This patch set is still desirable. Here is a rebased version of the v5
patches. I haven't applied any corrections or review comments.
From 94879f695ff8961255c2daa46b81ce378a55732d Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 13 Aug 2024 14:15:54 +1200
Subject: [PATCH v6 1/3] Provide t
On 19.08.24 08:29, Thomas Munro wrote:
Here is a slightly better version of patch 0003. I removed some
unnecessary refactoring, making the patch smaller.
FTR I wrote a small program[1] for CI to test the assumptions about
Windows in 0001. I printed out the addresses of the objects, to
confirm
On 16.08.24 02:48, Thomas Munro wrote:
2. A similar argument applies to Windows canonicalisation. CREATE
COLLATION isn't doing it. CREATE DATABASE is, but again, what is the
point? See previous.
I don't really know about Windows locales. But we are doing
canonicalization of ICU locale nam
On Tue, Aug 13, 2024 at 5:45 PM Thomas Munro wrote:
> Over on the discussion thread about remaining setlocale() work[1], I
> wrote out some long boring theories about $SUBJECT.
Just as an FYI/curiosity, I converted my frustrations with
localeconv() into a request[1] that POSIX consider standardis
Here is a slightly better version of patch 0003. I removed some
unnecessary refactoring, making the patch smaller.
FTR I wrote a small program[1] for CI to test the assumptions about
Windows in 0001. I printed out the addresses of the objects, to
confirm that different threads were looking at di
On Thu, Aug 15, 2024 at 11:11 PM Heikki Linnakangas wrote:
> There's a similar function in initdb, check_locale_name. I wonder if
> that could reuse the same code.
Thanks, between this comment and some observations from Peter E and
Tom, I think I have a better plan now. I think they should *not*
On 15/08/2024 11:03, Thomas Munro wrote:
Here's a new patch to add to this pile, this time for check_locale().
I also improved the error handling and comments in the other patches.
There's a similar function in initdb, check_locale_name. I wonder if
that could reuse the same code.
I wonder if
Here's a new patch to add to this pile, this time for check_locale().
I also improved the error handling and comments in the other patches.
From 4831ff4373b9d713c78e303d9758de347aadfc2f Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 13 Aug 2024 14:15:54 +1200
Subject: [PATCH v3 1/3] Provid
On Tue, Aug 13, 2024 at 6:23 PM Heikki Linnakangas wrote:
> Patch 3 makes sense too, some comments on the details:
> The #ifdefs and the LCONV_MEMBER stuff makes it a bit hard to follow
> what happens in each implementation strategy. I wonder if it would be
> more clear to duplicate more code.
I
Here's another mystery from Windows + MinGW. Although "fairywren" is
green, that is because it lacks ICU, which would activate extra tests.
CI is green too, but the optional CI task "Windows - Server 2019,
MinGW64 - Meson" has ICU and it is now failing if you trigger it[1]
after commit 35eeea62, i
On Tue, Aug 13, 2024 at 11:25 PM Thomas Munro wrote:
> On Tue, Aug 13, 2024 at 6:23 PM Heikki Linnakangas wrote:
> > On 13/08/2024 08:45, Thomas Munro wrote:
> > Patches 1 and 2 look good to me.
>
> Thanks. I went ahead and pushed these ones. A couple of Macs in the
> build farm are failing, as
On Tue, Aug 13, 2024 at 6:23 PM Heikki Linnakangas wrote:
> On 13/08/2024 08:45, Thomas Munro wrote:
> Patches 1 and 2 look good to me.
Thanks. I went ahead and pushed these ones. A couple of Macs in the
build farm are failing, as if they didn't include and
haven't seen the type locale_t. CI'
On 13/08/2024 08:45, Thomas Munro wrote:
Hi,
Over on the discussion thread about remaining setlocale() work[1], I
wrote out some long boring theories about $SUBJECT. Here are some
draft patches to try those theories out, and make a commitfest entry.
nl_langinfo_l() is a trivial drop-in replacem
20 matches
Mail list logo
