Re: Collation versions on Windows (help wanted, apply within) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Collation versions on Windows (help wanted, apply within)
Date
Msg-id CA+hUKGJiTJOk7k_B-4=92mMtSJiqTMeN4DxSdUfYwjqEOMyOUQ@mail.gmail.com
Whole thread Raw
In response to Re: Collation versions on Windows (help wanted, apply within)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Collation versions on Windows (help wanted, apply within)
Re: Collation versions on Windows (help wanted, apply within)
List pgsql-hackers
On Wed, Nov 27, 2019 at 10:38 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 2019-11-26 21:39, Thomas Munro wrote:
> > On Fri, Nov 8, 2019 at 12:44 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> >> The reason for returning an empty string for "C" and "POSIX" is the
> >> following comment for get_collation_actual_version():
> >>
> >>   * A particular provider must always either return a non-NULL string or return
> >>   * NULL (if it doesn't support versions).  It must not return NULL for some
> >>   * collcollate and not NULL for others.
> >>
> >> I'm not sure why, or if that really makes sense.
> >
> > Peter E, do you have any thoughts on this question?
>
> Doesn't make sense to me either.
>
> We need to handle the various combinations of null and non-null stored
> and actual versions, which we do, but that only applies within a given
> collcollate.  I don't think we need the property that that comment calls
> for.

While wondering about that, I noticed the "C.UTF-8" encoding (here on
a glibc system):

postgres=# \pset null <NULL>
Null display is "<NULL>".
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>
 C.UTF-8    | c            |            6 | C.UTF-8     | C.UTF-8    | 2.28
 en_NZ.utf8 | c            |            6 | en_NZ.utf8  | en_NZ.utf8 | 2.28
 en_NZ      | c            |            6 | en_NZ.utf8  | en_NZ.utf8 | 2.28
(7 rows)

I wonder if we should do something to give that no collversion, since
we know that it's really just another way of spelling "binary sort
please", or if we'd be better off not trying to interpret the names
locale -a spits out.

Juan Jose,

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?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: AW: Missing constant propagation in planner on hash quals causes join slowdown
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: non-exclusive backup cleanup is mildly broken