Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nz29x-0000TZ-2g for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jun 2022 20:20:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nz29v-00026g-TU for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jun 2022 20:20:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nz29v-00026X-I9 for pgsql-hackers@lists.postgresql.org; Wed, 08 Jun 2022 20:20:07 +0000 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nz29t-0008Il-Aa for pgsql-hackers@postgresql.org; Wed, 08 Jun 2022 20:20:06 +0000 Received: by mail-lj1-x229.google.com with SMTP id l18so16628280lje.13 for ; Wed, 08 Jun 2022 13:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MN7zhMS6vVEHzW3uFJUNJeoyJrpMlZVLRyhtCn6LC7c=; b=Esl4eBB/+GCIVdC3MJkD6qXki7u8DKSMt5aoR2d0CB9ilGfO9hrVG7XkwkRNQVqa+W 4zeK0ul6uoTlq63dszzmbW8JcSAdbkUZXQ58JSinFjkp2FKJPfDek10p7FookFe7BjjC Upbgnij7GNh5hJjLn+UMjb6X5rnF65sSL9a/RPaD54IrOpzFcYx4mI7pWzXdviRuVFcM PCRc8IaRcRi4qqAl9DGcqk7dGTwjKKinibGQBaKju9VVDub7UlbtUkQR7Zjg+EDZsE/s iSYo3qwkKz6SRwGX4WRri808hBWCU3BeKSTwbxnG+Pnse7po6VFJlFVgXK6toIOpfaBe HbGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MN7zhMS6vVEHzW3uFJUNJeoyJrpMlZVLRyhtCn6LC7c=; b=zBzeDUwzgNgsvhhB0jeHe4H3jx7YxKpNlVfglV2x+tHEg68zdOOqRGIOjGKd3QHDCq 6R2bkmtuNYQ6kfH+KEFdyczOztdUY+8DAVxAzo/xrz2/UZmuFSXcFAq5BUmiYjo4hTxH 2YRza7QjHkDk6zkOKhQzbTBJJ6PJfm9pjcn+ik3pm74Nf6DsWZBvVxGeVg39kRbtIudj 6Pju7T4UR1UBuuhM3nvqQDzBdhPRd8MRELml0uRn5ePQu/4TerufZJ6xN4vUXBqv+gUY X8mmIMSywA0sUh/MsDkBgr51F1Vxk2XoBkZoQ/g9wgkHYipFD5esyv9YTcfg3IQorosc fEMg== X-Gm-Message-State: AOAM531KwITSXhoZFWb8lD9Ej1PvzHtsKWoMJ9xIN+JboGxK8RDgBmwx 8HP8VgMiaoM2wxODpLEkMTfX2Rl79FrKfHZ0NO0= X-Google-Smtp-Source: ABdhPJxBwuTBaoJIG80dXZmlZLZh9SPRr3wi3W56sQ7VdHZm8JC9z64Rg+epTzPTml+/MR4jd5hRaAJ5f0Dro7zzCJ0= X-Received: by 2002:a2e:80d3:0:b0:255:5c62:7614 with SMTP id r19-20020a2e80d3000000b002555c627614mr24974460ljg.389.1654719603700; Wed, 08 Jun 2022 13:20:03 -0700 (PDT) MIME-Version: 1.0 References: <6b0bc332-ed6d-4848-a128-4dd63d1160a1@manitou-mail.org> <1738483.1654718503@sss.pgh.pa.us> In-Reply-To: <1738483.1654718503@sss.pgh.pa.us> From: Robert Haas Date: Wed, 8 Jun 2022 16:19:52 -0400 Message-ID: Subject: Re: Collation version tracking for macOS To: Tom Lane Cc: Daniel Verite , Thomas Munro , Rod Taylor , Jim Nasby , Jeremy Schneider , Peter Eisentraut , Pgsql-Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jun 8, 2022 at 4:02 PM Tom Lane 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