Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3ikw-0006lR-6F for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2020 15:56:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j3iku-0006Ia-RV for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2020 15:56:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3iku-0006IM-Hy for pgsql-hackers@lists.postgresql.org; Mon, 17 Feb 2020 15:56:20 +0000 Received: from [64.147.123.24] (helo=wout1-smtp.messagingengine.com) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j3ikq-0000P3-Vs for pgsql-hackers@postgresql.org; Mon, 17 Feb 2020 15:56:19 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 53EB0620; Mon, 17 Feb 2020 10:56:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 17 Feb 2020 10:56:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=MzF/bbeYVkx0IyNfg4PCUxVfuT3HJMgQdgwo1S6Jf 3c=; b=mN+6lhIC5I+SedNuntvV3vwWIITdiOKbQZeuTB9WOmC7hoO5pEaJFviLA bPTtr4EW+Rhnc33bTv+uPtAk967Ejdv3fxPaAr6ZTh6yQD/GqqW+cTLoHly/RN0B 34Se5LvMmsADYbeLh4ONhq2KO81z/DNn7/DJ4nDhCnUxFgmISamRJahR310M976E 7gefSU1D6mh2+wANLo1gqRyaTajhbiM9ga5/+5YQ14KjknPd4sYWH3/OeefosRnP bEKAwcxH/FpZSN7Bu5I6pGfX8QeaQl+95UO29hhvdFbNNCkt+9/s4rFxqEqgfcvf ik6n2ZM8iA7hBIbvEOtyEM3PCrX/Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeeigdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefleenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucffohhmrghinhepvdhnughquhgrughrrghnthdrtgho mhenucfkphepleefrddvgedvrddvheehrdduuddvnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhhtsedv nhguqhhurggurhgrnhhtrdgtohhm X-ME-Proxy: Received: from april.pezone.net (p5df2ff70.dip0.t-ipconnect.de [93.242.255.112]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C3AF328005E; Mon, 17 Feb 2020 10:56:02 -0500 (EST) Subject: Re: Unicode normalization SQL functions To: Andreas Karlsson , Daniel Verite References: <623fa07e-348f-4273-afa4-7110ad43ca57@manitou-mail.org> <43f13518-010a-8319-8013-f319522ea719@2ndquadrant.com> <26150b35-240f-941c-e5a7-24f2d489b316@proxel.se> Cc: pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Mon, 17 Feb 2020 16:56:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <26150b35-240f-941c-e5a7-24f2d489b316@proxel.se> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.147.123.24 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-02-13 01:23, Andreas Karlsson wrote: > A potential optimization would be to merge utf8_to_unicode() and > pg_utf_mblen() into one function in unicode_normalize_func() since > utf8_to_unicode() already knows length of the character. Probably not > worth it though. This would also require untangling the entire encoding API. > It feels a bit wasteful to measure output_size in > unicode_is_normalized() since unicode_normalize() actually already knows > the length of the buffer, it just does not return it. Sure, but really most string APIs work like that. They surely know the string length internally, but afterwards you often have to call strlen() again. > A potential optimization for the normalized case would be to abort the > quick check on the first maybe and normalize from that point on only. If > I can find the time I might try this out and benchmark it. Are you sure this would always be valid? The fact that this wasn't mentioned in UTR #15 makes me suspicious. > Nitpick: "split/\s*;\s*/, $line" in generate-unicode_normprops_table.pl > should be "split /\s*;\s*/, $line". done > What about using else if in the code below for clarity? > > + if (check == UNICODE_NORM_QC_NO) > + return UNICODE_NORM_QC_NO; > + if (check == UNICODE_NORM_QC_MAYBE) > + result = UNICODE_NORM_QC_MAYBE; done > Remove extra space in the line below. > > + else if (quickcheck == UNICODE_NORM_QC_NO ) I didn't find this in my local copy. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services