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 1rN0kg-008ZUI-GQ for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 01:17:59 +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 1rN0kf-008hrH-CM for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 01:17:57 +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 1rN0ke-008hr8-Ty for pgsql-hackers@lists.postgresql.org; Tue, 09 Jan 2024 01:17:57 +0000 Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rN0kb-000Z4a-VP for pgsql-hackers@postgresql.org; Tue, 09 Jan 2024 01:17:56 +0000 Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-67f7bd86cafso20637556d6.0 for ; Mon, 08 Jan 2024 17:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ardentperf-com.20230601.gappssmtp.com; s=20230601; t=1704763072; x=1705367872; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=LNHQkGUDeDNHF/Xo/meU1dIypnDzyIPs/qCtvSYIZBU=; b=McLZjQIN0Aqjx3lUqA0/2BNVaxxh4T9LlEFfb4RsN13J+fneEcQ8hTTRLeJYONDaEE UdgU/4xFZ9dYgOTxh33pJMxMzrMWVtZhWTeloayGlzZMp17S82VKcKNpf9F4maqIgBJ0 gsoFxCcYwBSmzkcnhvLOaaAW3KDwckl9uMyjt5W7aemFbxvs8ryzEethAFNDSnw7HMwK Hg8QD7KZ+efbHCx03q55WqIeniA/cC3nql8nCMkt3xdNmXoCPtYZDrav9M4T1fgD3exZ k2tU1w9xzgnzw3QZj0NxdGxXH3UBLmjpJmgAz7XjbHxdLyHW2Nm2TiDwUup2x4D7evh5 rOAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704763072; x=1705367872; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LNHQkGUDeDNHF/Xo/meU1dIypnDzyIPs/qCtvSYIZBU=; b=ic1HhhlNOdReXczqzO0sLZd6u7JMPwbbeadmOeZpAKWR6MQP/d4YcZTAResfLoEgOb VVEhc3qVrZC5OZ4f9Ho7n06ZkCicwPCI1FZEReyL7bMOrl3HhGJd0qzkb8X/USWczywz 4OjgqwIeQNl2DOZ6+z7ILENLB20edBE3IUkhakc0AoPXJjJwRyurCmQsf7fgVLbFcHul eLpkrkRP1qLYrj+Z80lrvv6dktIRifthEJ3YqWvaCQ1yvonfsOTRrn+GIKpzJuDBUTYF s1Aiv5rBRjI7SzXO/nQB01aqKGMuNKflZ5txBvpOfs51eslT81mgDMsFwuLd2JJjLkhx 5/iQ== X-Gm-Message-State: AOJu0YzAzydrdb3EvL5prKB8wch7nENL7LQ9XRWAfykJUY1HmbkFfAsG iPLr5QyPKgnQseFUcGj2C5WZ1O2P9SQL X-Google-Smtp-Source: AGHT+IEh51qeX8DqZFfPu1Y1ykPdhHRVzj3X43RnLM/J/2pfsc+zvydRDaPKeBxgFSxMfWEF4Go97g== X-Received: by 2002:ad4:5762:0:b0:681:ad:4205 with SMTP id r2-20020ad45762000000b0068100ad4205mr4389995qvx.83.1704763072028; Mon, 08 Jan 2024 17:17:52 -0800 (PST) Received: from [192.168.197.220] (54-240-198-38.amazon.com. [54.240.198.38]) by smtp.gmail.com with ESMTPSA id z17-20020a0cfc11000000b00680ca85b06fsm465292qvo.31.2024.01.08.17.17.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jan 2024 17:17:51 -0800 (PST) Message-ID: <63cd8625-68fa-4760-844a-6b7f643336f2@ardentperf.com> Date: Mon, 8 Jan 2024 17:17:48 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Built-in CTYPE provider To: Jeff Davis , Daniel Verite Cc: Robert Haas , pgsql-hackers@postgresql.org References: <6b1370d5eaba5e8c42f54c05f7bc2b8e27b8db12.camel@j-davis.com> <804eb67b37f41d3afeb2b6469cbe8bfa79c562cc.camel@j-davis.com> Content-Language: en-US From: Jeremy Schneider In-Reply-To: <804eb67b37f41d3afeb2b6469cbe8bfa79c562cc.camel@j-davis.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 12/28/23 6:57 PM, Jeff Davis wrote: > > Attached a more complete version that fixes a few bugs, stabilizes the > tests, and improves the documentation. I optimized the performance, too > -- now it's beating both libc's "C.utf8" and ICU "en-US-x-icu" for both > collation and case mapping (numbers below). > > It's really nice to finally be able to have platform-independent tests > that work on any UTF-8 database. Thanks for all your work on this, Jeff I didn't know about the Unicode stability policy. Since it's formal policy, I agree this provides some assumptions we can safely build on. I'm working my way through these patches but it's taking a little time for me. I hadn't tracked with the "builtin" thread last summer so I'm coming up to speed on that now too. I'm hopeful that something along these lines gets into pg17. The pg17 cycle is going to start heating up pretty soon. I agree with merging the threads, even though it makes for a larger patch set. It would be great to get a unified "builtin" provider in place for the next major. I also still want to parse my way through your email reply about the two groups of callers, and what this means for user experience. https://www.postgresql.org/message-id/7774b3a64f51b3375060c29871cf2b02b3e85dab.camel%40j-davis.com > Let's separate it into groups. > (1) Callers that use a collation OID or pg_locale_t: > (2) A long tail of callers that depend on what LC_CTYPE/LC_COLLATE are > set to, or use ad-hoc ASCII-only semantics: In the first list it seems that some callers might be influenced by a COLLATE clause or table definition while others always take the database default? It still seems a bit odd to me if different providers can be used for different parts of a single SQL. But it might not be so bad - I haven't fully thought through it yet and I'm still kicking the tires on my test build over here. Is there any reason we couldn't commit the minor cleanup (patch 0001) now? It's less than 200 lines and pretty straightforward. I wonder if, after a year of running the builtin provider in production, whether we might consider adding to the builtin provider a few locales with simple but more reasonable ordering for european and asian languages? Maybe just grabbing a current version of DUCET with no intention of ever updating it? I don't know how bad sorting is with plain DUCET for things like french or spanish or german, but surely it's not as unusable as code point order? Anyone who needs truly accurate or updated or customized linguistic sorting can always go to ICU, and take responsibility for their ICU upgrades, but something basic and static might meet the needs of 99% of postgres users indefinitely. By the way - my coworker Josh (who I don't think posts much on the hackers list here, but shares an unhealthy inability to look away from database unicode disasters) passed along this link today which I think is a fantastic list of surprises about programming and strings (generally unicode). https://jeremyhussell.blogspot.com/2017/11/falsehoods-programmers-believe-about.html#main Make sure to click the link to show the counterexamples and discussion, that's the best part. -Jeremy PS. I was joking around today that the the second best part is that it's proof that people named Jeremy are always brilliant within their field. 😂 Josh said its just a subset of "always trust people whose names start with J" which seems fair. Unfortunately I can't yet think of a way to shoehorn the rest of the amazing PG hackers on this thread into the joke. -- http://about.me/jeremy_schneider