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

From Mark Dilger
Subject Re: Collation version tracking for macOS
Date
Msg-id A0C774E0-55C0-4566-A520-C0ED7D943B97@enterprisedb.com
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> On Jun 7, 2022, at 1:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> This is not the concern that I have.  I agree that if we tell a user
> that collation X changed behavior and he'd better reindex his indexes
> that use collation X, but none of them actually contain any cases that
> changed behavior, that's not a "false positive" --- that's "it's cheaper
> to reindex than to try to identify whether there's a problem".

I don't see this problem as limited to indexes, though I do understand why that might be the most common place for the
problemto manifest itself. 

As a simple example, text[] constructed using array_agg over sorted data can be corrupted by a collation change, and
reindexwon't fix it. 

If we extend the table-AM interface to allow query quals to be pushed down to the table-AM, we might develop table-AMs
thatcare about sort order, too. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Collation version tracking for macOS
Next
From: Justin Pryzby
Date:
Subject: Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch