Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2m1A-000aim-0t for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Mar 2026 08:12:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2m19-008fnS-0J for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Mar 2026 08:12:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2m18-008fnK-1h for pgsql-hackers@lists.postgresql.org; Wed, 18 Mar 2026 08:12:38 +0000 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w2m15-00000000K83-0wKl for pgsql-hackers@lists.postgresql.org; Wed, 18 Mar 2026 08:12:37 +0000 Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8030C140023D; Wed, 18 Mar 2026 04:12:35 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-08.internal (MEProxy); Wed, 18 Mar 2026 04:12:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eisentraut.org; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1773821555; x=1773907955; bh=ZMwA3GFe9O5bBbPxX0PTWFl5E6I50tej9GM+YcKWGTY=; b= Bt7jDOH7hO7Pl/u/wVQhxWDV4GGmxOxWv0nrjfwe4iSNv1MilN68v6mX8hFE/xH+ za0B3DExyCUdloQMytfWBUxKnoMOSrCRNNrSWzfR4BNTHeNJ8gFeK2MXmJ5Po3R9 2G69b+Pf7spYknS1mSWfulmjI50S2PZavQieEy7pqokY+qazP4Yvsnh/jbk1JK4i M90ZdJ1MYh/f0ExLsRS0MMBlP8XZTkQ08JZ7BPwItGDTf4zDJ/26is7SV/AdX28u zF03phouADpn5vZVPZ+0WjnfuKk3kQYtWpcQ235984hLNmQJgsb52JO6D5XwQ/cR kppm8lX8yTs7A+kvF9B1OQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1773821555; x=1773907955; bh=Z MwA3GFe9O5bBbPxX0PTWFl5E6I50tej9GM+YcKWGTY=; b=1BjimpAnZvMI6JpA9 xYfpOfBIDi/urbdl9FaBrmP4vUjIpjbClgcWheeunPs4908z1KbtuQG+ovoKTZPR fWVm52HsP2Arqa9mtMRVQs+sCBn6RNIc98aW45ieIX6mowRM4Es+R5xa43ySvOcC j1yag76Rm+BxC6EjGVNHkBzefQPqvBclQmCFyhFE2EIP7noeWpGNv1T5tg3DyosX c2JRhowA6JFMSyx+4RBUvJKi8ypjJTAfylaeo0TzWkgD00NXbMhC0tBkemoS3lwL ld1TZv+7URXAilKs3+UnUoSvv82zVO7k4phGKp/pBHuphQsKEquY3TiJsOUYTQYU sNbFg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdeftdefieduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvfhfhjggtgfesthejredttddvjeenucfhrhhomheprfgvthgvrhcu gfhishgvnhhtrhgruhhtuceophgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgqeenuc ggtffrrghtthgvrhhnpeehiedvhfeuhfeugefgfeehgeejtdevuefhtefhueefvddugfdt ueehgfefudfhffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehpvghtvghrsegvihhsvghnthhrrghuthdrohhrghdpnhgspghrtghpthhtohep vddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggrnhhivghlsehmrghnihhtoh huqdhmrghilhdrohhrghdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehlihhs thhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Mar 2026 04:12:34 -0400 (EDT) Message-ID: Date: Wed, 18 Mar 2026 09:12:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Supporting non-deterministic collations with tailoring rules. To: Daniel Verite , pgsql-hackers@lists.postgresql.org References: Content-Language: en-US From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 15.03.26 19:52, Daniel Verite wrote: > [resent for the list] > > Peter Eisentraut wrote: > >>> To me, the most plausible fix on the Postgres side would be to pass >>> UCOL_DEFAULT instead of UCOL_DEFAULT_STRENGTH as in the attached, >>> which lets the user specify the strength in the rule, as the OP did in [1]. >> >> With this change, I don't see that the bug reported in ICU-22456 is >> fixed. See attached my test case. >> >> What change of behavior are you expecting from your patch? Should there >> be test cases? > > Indeed it does not fix the behavior reported in ICU-22456 > (=collation properties being "reset" when adding rules) > It fixes the fact that specificying the strength in the rule itself > will be taken into account instead of the strength being > forced to tertiary. > > PFA a new patch with a specific test case added. > > With regards to reports on pgsql-bugs, it fixes #18771 > and the second part of #19425. > It does not fix #19045, which looks the same as ICU-22456 > It also does not fix the first part of #19425 (which looks the > same as #19045). We cannot fix that in Postgres AFAIU. > However adding the strength or other collation properties in > the rules can be used as a workaround against the ICU-22456 > issue, provided the attached change is made. Ok, committed. Thoughts on backpatching? Seems like a straightforward bug fix.