From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Rod Taylor <rbt(at)rbt(dot)ca>, Jim Nasby <nasbyj(at)amazon(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collation version tracking for macOS |
Date: | 2022-06-07 19:43:32 |
Message-ID: | 1310017.1654631012@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Jun 8, 2022 at 3:58 AM Rod Taylor <rbt(at)rbt(dot)ca> wrote:
>> Is this more involved than creating a list of all valid Unicode characters (~144 thousand), sorting them, then running crc32 over the sorted order to create the "version" for the library/collation pair? Far from free but few databases use more than a couple different collations.
> Collation rules have multiple levels and all kinds of quirks, so that
> won't work.
Yeah, and it's exactly at the level of quirks that things are likely
to change. Nobody's going to suddenly start sorting B before A.
They might, say, change their minds about where the digram "cz"
sorts relative to single letters, in languages where special rules
for that are a thing.
The idea of fingerprinting a collation's behavior is interesting,
but I've got doubts about whether we can make a sufficiently thorough
fingerprint.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-06-07 19:46:50 | Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list |
Previous Message | Robert Haas | 2022-06-07 19:36:45 | Re: Collation version tracking for macOS |