On Tue, Nov 3, 2020 at 1:51 PM David Rowley <dgrowleyml@gmail.com> wrote:
> On Tue, 3 Nov 2020 at 12:29, David Rowley <dgrowleyml@gmail.com> wrote:
> > Running low on ideas for now, so thought I'd post this in case it
> > someone thinks of something else.
>
> FWIW, the attached does fix the issue for me. It basically just calls
> the function that converts the windows-type "English_New Zealand.1252"
> locale name string into, e.g. "en_NZ". Then, since GetNLSVersionEx()
> wants yet another variant with a - rather than an _, I've just added a
> couple of lines to swap the _ for a -. There's a bit of extra work
> there since IsoLocaleName() just did the opposite, so perhaps doing it
> that way was lazy of me. I'd have invented some other function if I
> could have thought of a meaningful name for it, then just have the ISO
> version of it swap - for _.
Thanks! Hmm, it looks like Windows calls the hyphenated ISO
language-country form a "tag". It makes me slightly nervous to ask
for the version of a transformed name with the encoding stripped, but
it does seem entirely plausible that it gives the answer we seek. I
suppose if we were starting from a clean slate we might want to
perform this transformation up front so that we have it in datcollate
and then not have to think about the older form ever again. If we
decided to do that going forward, the last trace of that problem would
live in pg_upgrade. If we ever extend pg_import_system_collations()
to cover Windows, we should make sure it captures the tag form.
> It would be good if this could also be tested on Visual Studio version
> 12 as I see IsoLocaleName() does something else for anything before
> 15. I only have 10 and 17 installed and I see we don't support
> anything before 12 on master per:
I think others have mentioned that it might be time to drop some older
Windows versions. I don't follow that stuff, so I've quietly added a
name to the CC list and will hope for the best :-)
