Re: WIN32 pg_import_system_collations - Mailing list pgsql-hackers

From Juan José Santamaría Flecha
Subject Re: WIN32 pg_import_system_collations
Date
Msg-id CAC+AXB0kd+YgF408sy5c2Bsa3PQdiSS6YJZLq6TMx33_WTJ-rA@mail.gmail.com
Whole thread Raw
In response to Re: WIN32 pg_import_system_collations  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: WIN32 pg_import_system_collations
List pgsql-hackers

On Tue, Jan 25, 2022 at 11:40 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 24.01.22 22:23, Dmitry Koval wrote:
 
Thanks for looking into this.
 
> +/*
> + * Windows will use hyphens between language and territory, where POSIX
> + * uses an underscore. Simply make it POSIX looking.
> + */
> + hyphen = strchr(localebuf, '-');
> + if (hyphen)
> +    *hyphen = '_';
>
> After this block modified collation name is used in function
>
> GetNLSVersionEx(COMPARE_STRING, wide_collcollate, &version)
>
> (see win32_read_locale() -> CollationFromLocale() -> CollationCreate()
> call). Is it correct to use (wide_collcollate = "en_NZ") instead of
> (wide_collcollate = "en-NZ") in GetNLSVersionEx() function?

The problem that David Rowley addressed was coming from Windows collations in the shape of "English_New Zealand", GetNLSVersionEx() will work with both "en_NZ" and "en-NZ". You can check collversion in pg_collation in the patched version.

I don't really know if this is necessary anyway.  Just create the
collations with the names that the operating system presents.  There is
no requirement to make the names match POSIX.

If you want to make them match POSIX for some reason, you can also just
change the object name but leave the collcollate/collctype fields the
way they came from the OS.

I think there is some value in making collation names consistent across different platforms, e.g. making user scripts more portable. So, I'm doing that in the attached version, just changing the object name.

Regards,

Juan José Santamaría Flecha
 
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: "David G. Johnston"
Date:
Subject: Re: Skipping logical replication transactions on subscriber side