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 1qBXG8-0004MR-Dt for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jun 2023 09:02:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qBXG7-00065c-60 for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jun 2023 09:02:43 +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 1qBXG6-00065M-O4 for pgsql-hackers@lists.postgresql.org; Tue, 20 Jun 2023 09:02:42 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qBXG3-003D0J-UC for pgsql-hackers@postgresql.org; Tue, 20 Jun 2023 09:02:41 +0000 Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-25efb821778so1264012a91.3 for ; Tue, 20 Jun 2023 02:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20221208.gappssmtp.com; s=20221208; t=1687251759; x=1689843759; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=mhOoPF5SatREd5uQUAnn+ZQIkS6a9/LXYJvr9cvByFs=; b=NRgYSJpFstJ26ZIlnIeQVuqlqm7w/RioPssijM9QaZtcTg49eE5SsXgqmvHDI3wa3x X6uTfzaQ0qbYMjsvXtKCaC2ZHluF1A3MxnIRzbY++nK5ggq7hUuZagFB9Cegs9TXVp21 8IahuzzDmcS71ADcN3iiPYbygczcNr28BvhORII6vl4faJMMKETWmTFwIjtvWuMneu/U NaYVpHiJZA7PVoX9Txe6re+jV9Wj6lYafufFY8HXx6McXt3QAILtbZUbhrixpIEMad33 VDYcujvT8p/dsI0all+p3DxXlehVufQatGL8g2IS2nILmNQRkfkOihOwDgoPkzs+ntTP 1fcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687251759; x=1689843759; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mhOoPF5SatREd5uQUAnn+ZQIkS6a9/LXYJvr9cvByFs=; b=LCOPmJLzEBMM94vhZJEtHbJM/2PY3xAjo+22IDFvs4rLTo2KzdCwK1Sm2bXLcAfCrz I2JMfYeejmWzYX9iA3ihQ7jzsnmRAPEjSWtUO6sWzqmtePd/BWjQLAHXyFf07uPXhWoy nezorH8aY3YPysn8BUNzSDJ+jnhb0DYxiFG1ZzK+scNJGVJkYLcWR9bkB7LdX/1/y7/P Ptwr/h5ohOEemYkA+n3IkD4HeyFPza3mpoetAEbGQjt7GPn6hWNud546Tp2X8KmNPdtv UMfTNC0ltjoHje41KOyHUs85v4p6x3uWP9JrY0NSPVf9RApc7Lb/vyILbljrUX6kErRw 6zzQ== X-Gm-Message-State: AC+VfDzHm+YuxnJ/n+0HNy/IRjeGWBvI3MnUFapWL1ktusbd5ZzwCREc Ykvb8UkmFC/D0o0JjQEGsaoYUTKBlYNPaGhu8YfQgg== X-Google-Smtp-Source: ACHHUZ69iat/BNLgNrLmtBHBfGvGT1HrHvnqIK8rPKfQCaXfKukVQREPjNdmlVF2+1MYQ3gs8BrHQg== X-Received: by 2002:a17:90a:c905:b0:25c:19e:9424 with SMTP id v5-20020a17090ac90500b0025c019e9424mr8293175pjt.10.1687251758829; Tue, 20 Jun 2023 02:02:38 -0700 (PDT) Received: from jeff-laptop.lan (c-73-170-46-202.hsd1.ca.comcast.net. [73.170.46.202]) by smtp.gmail.com with ESMTPSA id r23-20020a634417000000b005143448896csm991113pga.58.2023.06.20.02.02.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jun 2023 02:02:38 -0700 (PDT) Message-ID: Subject: collation-related loose ends before beta2 From: Jeff Davis To: pgsql-hackers@postgresql.org Cc: Daniel Verite , Peter Eisentraut , Andrew Gierth , Tom Lane , Joe Conway , Robert Haas , "Jonathan S. Katz" , Peter Geoghegan , Thomas Munro Date: Tue, 20 Jun 2023 02:02:36 -0700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Status on collation loose ends: 1. There's an open item "Switch to ICU for 17". It's a little bit confusing exactly what that means, and the CF entry refers to two items, one of which is the build-time default to --with-icu. As far as I know, building with ICU by default is a settled issue with no objections. The second issue is the initdb default, which is covered by the other open item. So I will just close that open item unless someone thinks I'm missing something. 2. Open item about the unfriendly rules for choosing an ICU locale at initdb time. Tom, Robert, and Daniel Verite have expressed concerns (and at least one objection) to initdb defaulting to icu for --locale- provider. Some of the problems have been addressed, but the issue about C and C.UTF-8 locales is not settled. Even if it were settled I'm not sure we'd have a clear consensus on all the details. I don't think this should proceed to beta2 in this state, so I intend to revert back to libc as the default for initdb. [ I believe we do have a general consensus that ICU is better, but we can signal it other ways: through documentation, packaging, etc. ] 3. The ICU conversion from "C" to "en-US-u-va-posix": cut out this code (it was a small part of a larger change). It's only purpose was consistency between ICU versions, and nobody liked it. It's only here right now to avoid test failures due to an order-of-commits issue; but if the initdb default goes back to libc it won't matter and I can remove it. 4. icu_validation_level WARNING or ERROR: right now an invalid ICU locale raises a WARNING, but Peter Eisentraut would prefer an ERROR. I'm still inclined to leave it as a WARNING for one release and increase it to ERROR later. But if the default collation provider goes back to libc, the risk of ICU validation errors goes way down, so I don't object if Peter would like to change it back to an ERROR. Regards, Jeff Davis