On Tue, Dec 17, 2019 at 1:40 AM Juan José Santamaría Flecha
<juanjo.santamaria@gmail.com> wrote:
> On Mon, Dec 16, 2019 at 1:26 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Wed, Nov 27, 2019 at 10:38 AM Peter Eisentraut
>>
>> Would you mind posting the full output of the above query (with <NULL>
>> showing) on a Windows system after running initdb with the -v2 patch,
>> so we can see how the collations look?
>
> Sure, you can find attached the full output with ICU.
Oh, I didn't realise until now that on Windows, initdb doesn't do
anything like "locale -a" to populate the system locales (which should
perhaps be done with EnumSystemLocalesEx(), as shown in Noah's nearby
problem report). So you have to define them manually, and otherwise
most people probably just use the default.
> This is a resume to illustrate an issue with locale = 'C':
>
> postgres=# CREATE COLLATION c_test (locale = 'C');
> CREATE COLLATION
> postgres=# select collname, collprovider, collencoding, collcollate, collctype, collversion from pg_collation ;
> collname | collprovider | collencoding | collcollate | collctype | collversion
> ------------------------+--------------+--------------+------------------+------------------+-------------
> default | d | -1 | | | <NULL>
> C | c | -1 | C | C | <NULL>
> POSIX | c | -1 | POSIX | POSIX | <NULL>
> ucs_basic | c | 6 | C | C | <NULL>
> und-x-icu | i | -1 | und | und | 153.97
> [... resumed ...]
> c_test | c | 6 | C | C |
> (757 rows)
>
> Shouldn't it be NULL?
Yeah, it should. I'll post a new patch next week that does that and
also removes the comment about how you can't have a mixture of NULL
and non-NULL, and see if I can identify anything that depends on that.
If you'd like to do that, please go ahead.
