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.94.2) (envelope-from ) id 1sMXQE-002tdd-4z for pgsql-bugs@arkaria.postgresql.org; Wed, 26 Jun 2024 18:31:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sMXQC-005wK3-Dz for pgsql-bugs@arkaria.postgresql.org; Wed, 26 Jun 2024 18:31:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMXQA-005wJv-O3 for pgsql-bugs@lists.postgresql.org; Wed, 26 Jun 2024 18:31:08 +0000 Received: from fhigh8-smtp.messagingengine.com ([103.168.172.159]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMXQ6-003gvb-Ep for pgsql-bugs@lists.postgresql.org; Wed, 26 Jun 2024 18:31:06 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 27FB811401A8; Wed, 26 Jun 2024 14:31:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 26 Jun 2024 14:31:00 -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=fm1; t=1719426660; x=1719513060; bh=WXPhCHyuFDIZ32UiCDVPKKhCDNy+7hX2d3AAD+OCcSE=; b= DAwrvO7hAdcB4C0aop9nvjJMHUIFtF7E6ARCY7fCbBTq5q4b2CnVn1uJT/tRHKOY i//9yLO6tHCbSKsmQvoxcn3hfm30kKebkxjy4sezuvRZFmhve4mF6BeKbvmakA37 BAOilT2KNmgjMWrpXUq7W9gTyBEiuKnYpu5aZ/6uCqCppqZh8N7VGtCIlwE6gy+Z 0fyxC54LLbyHV3qbcaVWpecG5I25kp8T1lA6EPbWdU9129wuT+DDxd2tlVEr/+44 PaLzEN9EZy8f/ITRvLdvOEtwQsltJ5//YLcDSZs2u82Qz2QkLkHmrn/nUQhuRbkC ojM3EgYarhbmDLXXoL1xNA== 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-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719426660; x= 1719513060; bh=WXPhCHyuFDIZ32UiCDVPKKhCDNy+7hX2d3AAD+OCcSE=; b=H l1d3nthMcm5e0xWWBqN6Wj+zlO5VOrZgTRwdkiXAkFG6O7JpxqeXUbv+rykbkt1V I6hq9QyqKlN+bwvZptIVBeOubPSRYL9vAGOmeZ7/oEIvrei/zkYW41dTdG0wOv9x db1eQhelwRjrlccL/vknUxaHQeEDClMOTCGo2Zy6RxcaCkiqGrN59hBfJv+7HKMa VL66jK59+O2AYGFX4/WIgjbHkhUbdzGPdRq6NH7s9n1nizoRezHRZBbZ69AgQOuo WhXHga4Px8e3tNUQIGMx+pCsN1u3bmVzcVN4kSc+Rfl3g0BHqcgmqrnvIpHbSbK8 6+QrRZ2ZEstZ8FmPVYueQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtddvgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttddvjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgqe enucggtffrrghtthgvrhhnpeetfefftddtgfehuddvveelhfeiheekueehveejjedttdet gfekveffteegleehtdenucffohhmrghinhepvghishgvnhhtrhgruhhtrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhes vghishgvnhhtrhgruhhtrdhorhhg X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 Jun 2024 14:30:59 -0400 (EDT) Message-ID: <30c9e733-9573-4500-b191-5a8a67b3795f@eisentraut.org> Date: Wed, 26 Jun 2024 20:30:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18523: String compare not consistent To: Laurenz Albe , patrick.van.dijk@gmail.com, pgsql-bugs@lists.postgresql.org References: <18523-d7b3cacb64d91cda@postgresql.org> <3a173a9aba9650ce7ddf22af9c413a3d64debbf4.camel@cybertec.at> Content-Language: en-US From: Peter Eisentraut In-Reply-To: <3a173a9aba9650ce7ddf22af9c413a3d64debbf4.camel@cybertec.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 26.06.24 17:59, Laurenz Albe wrote: > Interestingly, glibc and ICU disagree about that: > > SELECT '|1' < '01' COLLATE "de_DE.utf8" AS glibc, > '|1' < '01' COLLATE "de-AT-x-icu" AS icu; > > glibc │ icu > ═══════╪═════ > f │ t > (1 row) Let's work this out. The collation weights of the characters involved are: 0030 ; [.209F.0020.0002] # DIGIT ZERO 0031 ; [.20A0.0020.0002] # DIGIT ONE 007C ; [*06AF.0020.0002] # VERTICAL LINE So under the ICU default "noignore" behavior, the sort keys are: '|1' => 06AF 20A0 0000 0020 0020 0000 0002 0002 '01' => 209F 20A0 0000 0020 0020 0000 0002 0002 Therefore, '|1' < '01'. Under "shifted", the effective collation weights are: 0030 ; [.209F.0020.0002.FFFF] # DIGIT ZERO 0031 ; [.20A0.0020.0002.FFFF] # DIGIT ONE 007C ; [.0000.0000.0000.06AF] # VERTICAL LINE and the sort keys are: '|1' => 20A0 0000 0020 0000 0002 0000 06AF FFFF '01' => 209F 20A0 0000 0020 0020 0000 0002 0002 0000 FFFF FFFF Therefore, '|1' > '01'. That is what you get in glibc. (Older glibc use "shift-trimmed" behavior, which trims the trailing FFFF's, which doesn't affect the result in this case.) Under ICU (or rather CLDR), the '|' character is not actually a variable collation element by default, so you actually get the same result if you ask for "noignore" or "shifted" behavior. But you can make symbols variable with 'und-u-ka-shifted-kv-symbol', and then you will also get the same result as glibc. Further reading: - https://peter.eisentraut.org/blog/2023/04/12/how-collation-of-punctuation-and-whitespace-works - https://peter.eisentraut.org/blog/2023/05/16/overview-of-icu-collation-settings