Re: Collation version tracking for macOS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Collation version tracking for macOS
Date
Msg-id 1310017.1654631012@sss.pgh.pa.us
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Collation version tracking for macOS  (Thomas Munro <thomas.munro@gmail.com>)
Re: Collation version tracking for macOS  (Bruce Momjian <bruce@momjian.us>)
Re: Collation version tracking for macOS  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Jun 8, 2022 at 3:58 AM Rod Taylor <rbt@rbt.ca> wrote:
>> Is this more involved than creating a list of all valid Unicode characters (~144 thousand), sorting them, then
runningcrc32 over the sorted order to create the "version" for the library/collation pair? Far from free but few
databasesuse 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Collation version tracking for macOS
Next
From: David Rowley
Date:
Subject: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list