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

From Bruce Momjian
Subject Re: Collation version tracking for macOS
Date
Msg-id Yp/FO6pHcYZfOtnq@momjian.us
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun  7, 2022 at 03:43:32PM -0400, Tom Lane wrote:
> 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.

Rather than trying to figure out if the collations changed, have we ever
considered checking if index additions and lookups don't match the OS
collation and reporting these errors somehow?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list
Next
From: Peter Geoghegan
Date:
Subject: Re: Collation version tracking for macOS