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 1nyN2N-0001Ch-Ra for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jun 2022 00:25:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nyN2L-0002Vx-4Q for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jun 2022 00:25:33 +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 1nyN2K-0002V0-R6 for pgsql-hackers@lists.postgresql.org; Tue, 07 Jun 2022 00:25:32 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyN2F-0004ED-N0 for pgsql-hackers@postgresql.org; Tue, 07 Jun 2022 00:25:28 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2570POHb976280; Mon, 6 Jun 2022 20:25:24 -0400 From: Tom Lane To: Jim Nasby cc: Thomas Munro , Jeremy Schneider , Peter Eisentraut , pgsql-hackers Subject: Re: Collation version tracking for macOS In-reply-to: <0867fe37-abbd-77ba-aafc-572074978bb0@amazon.com> References: <381977b1-0898-cb6f-a427-3b5d873e81bd@enterprisedb.com> <231072.1654273317@sss.pgh.pa.us> <1874de62-6bec-4bc1-1d14-0a2730b125da@ardentperf.com> <366234.1654289888@sss.pgh.pa.us> <0867fe37-abbd-77ba-aafc-572074978bb0@amazon.com> Comments: In-reply-to Jim Nasby message dated "Mon, 06 Jun 2022 19:10:37 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <976278.1654561524.1@sss.pgh.pa.us> Date: Mon, 06 Jun 2022 20:25:24 -0400 Message-ID: <976279.1654561524@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jim Nasby writes: >> I think the real problem here is that the underlying software mostly >> doesn't take this issue seriously. > The first step to a solution is admitting that the problem exists. > Ignoring broken backups, segfaults and data corruption as a "rant" > implies that we simply throw in the towel and tell users to suck it up > or switch engines. There are other ways to address this short of the > community doing all the work itself. One simple example would be to > refuse to start if the collation provider has changed since initdb > (which we'd need to allow users to override). You're conveniently skipping over the hard part, which is to tell whether the collation provider has changed behavior (which we'd better do with pretty darn high accuracy, if we're going to refuse to start on the basis of thinking it has). Unfortunately, giving a reliable indication of collation behavioral changes is *exactly* the thing that the providers aren't taking seriously. regards, tom lane