public inbox for [email protected]  

help / color / mirror / Atom feed

From: Robert Haas <[email protected]>
To: Tom Lane <[email protected]>
Cc: Daniel Verite <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Rod Taylor <[email protected]>
Cc: Jim Nasby <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Pgsql-Hackers <[email protected]>
Subject: Re: Collation version tracking for macOS
Date: Wed, 8 Jun 2022 16:19:52 -0400
Message-ID: <CA+TgmoasMh+qLLncGMFPdLApyoU-9PhsW7+4D4QqqjzqrzO2uw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

On Wed, Jun 8, 2022 at 4:02 PM Tom Lane <[email protected]> wrote:
> I'm very skeptical of this process as being a reason to push users
> to reindex everything in sight.  If U+NNNN was not a thing last year,
> there's no reason to expect that it appears in anyone's existing data,
> and therefore the fact that it sorts differently this year is a poor
> excuse for sounding time-to-reindex alarm bells.

That seems completely wrong to me. It's not like a new character shows
up and people wait to start using it until it makes its way into
everyone's collation data. That is emphatically not what happens, I
would say. What happens is that people upgrade their libc packages at
one times and their postgres packages at another time, and it's
unlikely that they have any idea which order they do or did those
things. Meanwhile, people start using all the latest emojis. The idea
that the average PostgreSQL user has any idea whether a certain emoji
shows up in the data set for the first time before or after they
install the libc version that knows about it seems absurd. We don't
even know how to figure out which emojis the installed libc supports
-- if we did, we could reject data that we don't know how to sort
properly instead of ending up with corrupted indexes later. The user
has no more ability to figure it out than we do, and even if they did,
they probably wouldn't want to compare their stream of input data to
their collate definitions using some process external to the database.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

view thread (139+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Collation version tracking for macOS
  In-Reply-To: <CA+TgmoasMh+qLLncGMFPdLApyoU-9PhsW7+4D4QqqjzqrzO2uw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox