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 1nyzhN-0001lj-JU for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jun 2022 17:42:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nyzhL-0005fr-Sv for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jun 2022 17:42:27 +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 1nyzhL-0005fi-JC for pgsql-hackers@lists.postgresql.org; Wed, 08 Jun 2022 17:42:27 +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 1nyzhJ-00073q-Ds for pgsql-hackers@postgresql.org; Wed, 08 Jun 2022 17:42:26 +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 258HgLUo1707523; Wed, 8 Jun 2022 13:42:21 -0400 From: Tom Lane To: Robert Haas cc: Peter Geoghegan , Thomas Munro , Jeremy Schneider , Peter Eisentraut , pgsql-hackers Subject: Re: Collation version tracking for macOS In-reply-to: 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> <1315087.1654632634@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 08 Jun 2022 07:46:04 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1707521.1654710141.1@sss.pgh.pa.us> Date: Wed, 08 Jun 2022 13:42:21 -0400 Message-ID: <1707522.1654710141@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Tue, Jun 7, 2022 at 4:10 PM Tom Lane wrote: >> I mean by "false positive" is telling every macOS user that they'd better >> reindex everything every year, when in point of fact Apple changes those >> collations almost never. > Do we actually know that to be true? Given how fast things seem to be > getting added to Unicode, it wouldn't surprise me at all if they're > updating their Unicode tables for new characters with some regularity, > if nothing else, and that's a breaking change for us. Their POSIX collations seem to be legacy code that's entirely unrelated to any modern collation support; in particular the "UTF8" ones are that in name only. I'm sure that Apple are indeed updating the UTF8 data behind their proprietary i18n APIs, but the libc APIs are mostly getting benign neglect. Maybe the report that started this thread indicates that this is changing, but I'll believe that when I see it. regards, tom lane