From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collation versions on Windows (help wanted, apply within) |
Date: | 2019-12-16 00:26:10 |
Message-ID: | CA+hUKGJiTJOk7k_B-4=92mMtSJiqTMeN4DxSdUfYwjqEOMyOUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 27, 2019 at 10:38 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 2019-11-26 21:39, Thomas Munro wrote:
> > On Fri, Nov 8, 2019 at 12:44 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2019-12-16 01:43:48 | Re: non-exclusive backup cleanup is mildly broken |
Previous Message | Tom Lane | 2019-12-15 23:34:05 | Re: AW: Missing constant propagation in planner on hash quals causes join slowdown |