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 1qyh2E-00AIxv-BG for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Nov 2023 23:23:34 +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 1qyh2B-00G8kD-G8 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Nov 2023 23:23:31 +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 1qyh2A-00G8k5-RN for pgsql-hackers@lists.postgresql.org; Thu, 02 Nov 2023 23:23:31 +0000 Received: from firebrick.ash.relay.mailchannels.net ([23.83.222.59]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qyh27-004OnH-Ac for pgsql-hackers@postgresql.org; Thu, 02 Nov 2023 23:23:30 +0000 X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id EB22C14249B; Thu, 2 Nov 2023 23:23:22 +0000 (UTC) Received: from pdx1-sub0-mail-a250.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9C49C1425C4; Thu, 2 Nov 2023 23:23:22 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1698967402; a=rsa-sha256; cv=none; b=xKaW8VeBttIgErvwoMqL1D/QVZVdFhfg9LXdpDC9o6EVYxfrR21qc/bBJAPwwWSpJmjxBP MwT0Vyig0kYrNIK5JHoZScY2kRE/OpFhLqVuNN3hLwQCm4EE54KGV/rxrSs4j2zJlLwy8P v3gSRfNzRjo/dXlMNI2rH29pDBKpqdSd2NSeehnI02CzhnOstSbgraBSrQ+u/RvfZHfHpN eormX1TUxq6ciJXJc8TOQ8hme08NxHr3Iugbi8Z4yYoMOT3e5lKkm9mtgbxn8DiN47DaO+ Sa+PDClqWaOg3iXjQDLZDE6QlVVu+qGA4Hymeq7uHyfafTHaRgMHYYo4b3xyrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1698967402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YtA0zMgvWoWR6jkjOJywKqi/xdZbit35Q8UglwvSESI=; b=qzsfV/CF/S6nL475SLH99Hqy/NqTB1pTLi/Z69axGGyuBHfgQDJulrO4LiuZX8Vb22NOp0 GLTYBeR+P9C78vwZZ4Kp1t6XNrz310qmAR2OWUZ8UnbtXOOiQGohczy5+CG6C/KRxK5nMT EeO19S5Wuq145Bbe+FLTfrhlf3qwsSyEWNMG2XB2ODPsdbsTs3QgG0NIrx+HMM3gmsSRdz 8Y9069NBs7gHbxaVwf7rjriGMDvCMF9EPivnUxM0TvpyHwPntxy8J7Lvkv5Dj/uFPAGfxY 31bCJB0+3Ez7cAgS77rWtN0X085bPcp0FUrvw7kA3BuKGhKHxJcSrQVAuCDi2w== ARC-Authentication-Results: i=1; rspamd-86646d89b6-z69w7; auth=pass smtp.auth=dreamhost smtp.mailfrom=nico@cryptonector.com X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Tasty-Daffy: 7fe4ed1a401ad408_1698967402782_4066706971 X-MC-Loop-Signature: 1698967402782:172417201 X-MC-Ingress-Time: 1698967402782 Received: from pdx1-sub0-mail-a250.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.112.232.215 (trex/6.9.2); Thu, 02 Nov 2023 23:23:22 +0000 Received: from ubby21 (075-081-095-064.res.spectrum.com [75.81.95.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a250.dreamhost.com (Postfix) with ESMTPSA id 4SM0L16bVlz7G; Thu, 2 Nov 2023 16:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonector.com; s=dreamhost; t=1698967402; bh=YtA0zMgvWoWR6jkjOJywKqi/xdZbit35Q8UglwvSESI=; h=Date:From:To:Cc:Subject:Content-Type; b=cO0axvtMJf54+SM1ArchXIgHo2a8mzBNaVqCdZzoLRYoUArynlKK/FWYGrFvRbc2B GZYMeNIkpMyraiZwkvW1Eg1f5Fbfwv3Ci3bpc7gel8h8hf4Th+vwFSskyXOBufs4NS NEJfXI2bk6LpWuwnJRw4MGChmhGd5biqP+vj2mAV9i+YN+Ao2armK3vpI4Ff0pca2f OrPkhNknJYZ6l2cJTR7g5PcPa3cARwC2ANBPcCTLwd3RC3IdrwF7inOfrZ1Iu/vS3t j6meFUjHkPvCcE0I/7sToCZ0eQ8yBPqhnSxFhy8V5ivjea3YlnLIy5HgDuOuPuRXAe 8Dvkns9nMh2SA== Date: Thu, 2 Nov 2023 18:23:19 -0500 From: Nico Williams To: Jeff Davis Cc: Robert Haas , Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: Pre-proposal: unicode normalized text Message-ID: References: <33a31c45-2e80-1270-771a-b75f3920a5ec@eisentraut.org> <3941663a8e2f185d6acbbbc4f172c41dd3cfb6fe.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Oct 04, 2023 at 01:15:03PM -0700, Jeff Davis wrote: > > The fact that there are multiple types of normalization and multiple > > notions of equality doesn't make this easier. And then there's text that isn't normalized to any of them. > NFC is really the only one that makes sense. Yes. Most input modes produce NFC, though there may be scripts (like Hangul) where input modes might produce NFD, so I wouldn't say NFC is universal. Unfortunately HFS+ uses NFD so NFD can leak into places naturally enough through OS X. > I believe that having a kind of text data type where it's stored in NFC > and compared with memcmp() would be a good place for many users to be - > - probably most users. It's got all the performance and stability > benefits of memcmp(), with slightly richer semantics. It's less likely > that someone malicious can confuse the database by using different > representations of the same character. > > The problem is that it's not universally better for everyone: there are > certainly users who would prefer that the codepoints they send to the > database are preserved exactly, and also users who would like to be > able to use unassigned code points. The alternative is forminsensitivity, where you compare strings as equal even if they aren't memcmp() eq as long as they are equal when normalized. This can be made fast, though not as fast as memcmp(). The problem with form insensitivity is that you might have to implement it in numerous places. In ZFS there's only a few, but in a database every index type, for example, will need to hook in form insensitivity. If so then that complexity would be a good argument to just normalize. Nico --