Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDgmT-0002Jy-3P for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Jan 2023 07:04:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pDgmQ-0004DI-Ae for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Jan 2023 07:04:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDgmP-0004Aw-Or for pgsql-hackers@lists.postgresql.org; Fri, 06 Jan 2023 07:04:41 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pDgmJ-0006Bh-2T for pgsql-hackers@postgresql.org; Fri, 06 Jan 2023 07:04:40 +0000 Received: by mail-pj1-x102a.google.com with SMTP id j8-20020a17090a3e0800b00225fdd5007fso862590pjc.2 for ; Thu, 05 Jan 2023 23:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Zg2J60vJEMM6wgkjDxb6XrZ/NCI7Opr2vd53UX+g9QI=; b=DhkzSmjq6SqQyRB1Dvjv1gbR+SAOEWn9Hej1DJlS6UOAcLl3GKM9ZezsNazGEIjnB8 MyziaKmGm8tvjGWRDemkKuneCNvkt3YFX2nQHsx7vw9+B9X8Z0LpyND2B4H42NHhZbHg ESh1YlyDGYk3MZkm3W1tY9dpZYkMZPtDc7KmmRuAvc/n9XlXnlOHg53hzsVNjpXVQn1m PbNHCV02evQjE2U0MrLHlYbQtXagcZTYLlzHs5XcurSNUPFMGPFy9TNrpVoFLVIvFIOD dgFFIBCNjZLIs3i3W23Dd2mbitDTYV0qIYcnYmuFZijRVFb8WzkvVuuidraJU5vKIPe/ P7Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Zg2J60vJEMM6wgkjDxb6XrZ/NCI7Opr2vd53UX+g9QI=; b=uf56n8CjJptnDEpbSdn4585D3Sf8ku+ehXTcgT1Gxsd4/v4+fZ5iNH2gGOpXwlKm2L TcuNite/vxEuW58H+6dQaZKiBItzl/edO5opjvgq7nh3E/U1/z7xUky0jqrVpInnEvbY RWtxKOFbJOYQyno6ge5QUiTlEK2hfOu/NQ7y5QP/rI/z1Hltwffd8Qx6UR/ph1jI2WGl EpWuAIbYTVaMliFr8t5q5OVAX5D+yknNPK2TDmrMArQ0WRKFwLaZE94EgVRjo5Xxp1vW hT1t6iuhpUAa4obPrjR2eymtAw+2EMUk3BxtR3NiGPXWJX4g8gKZ6BDaBCBq5So65wF2 KT2A== X-Gm-Message-State: AFqh2ko63I8zBmcwF2G8iROVKQfSnrd58JNZZ2lpJjiUVa4OlwYQP6jy yERVhG3yxjgSoqhjzs3eioamcFNe9yGfvuaU X-Google-Smtp-Source: AMrXdXtBAWcAEX3halMHNmcfehgCrmm2GFnA9e702NAQf4DiiWshsu8W10NMp1F/cVJefyeGaFHceA== X-Received: by 2002:a17:90a:28c4:b0:219:158d:61c2 with SMTP id f62-20020a17090a28c400b00219158d61c2mr57608986pjd.19.1672988673989; Thu, 05 Jan 2023 23:04:33 -0800 (PST) Received: from [192.168.21.111] ([12.201.85.2]) by smtp.gmail.com with ESMTPSA id j23-20020a17090a061700b002262fcd92desm2316136pjj.7.2023.01.05.23.04.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 23:04:33 -0800 (PST) Message-ID: <0ab5c536cc778a5f27f51a6998fd4033bb1c21d8.camel@j-davis.com> Subject: Re: Rework of collation code, extensibility From: Jeff Davis To: Peter Eisentraut , pgsql-hackers@postgresql.org Date: Thu, 05 Jan 2023 23:04:32 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2023-01-04 at 22:46 +0100, Peter Eisentraut wrote: > It combines some refactoring that was previously posted with partial=20 > support for multiple ICU libraries with partial support for some new=20 > hooks.=C2=A0 Shouldn't those be three separate threads? Originally they felt more separate to me, too; but as I worked on them it seemed better to consider them as a patch series. Whatever is easier for reviewers works for me, though. > =C2=A0 I think the multiple=20 > ICU libraries already does have a separate thread; how does this > relate=20 > to that work? Multilib ICU support adds complexity, and my hope is that this patch set cleans up and organizes things to better prepare for that complexity. > =C2=A0 I don't know what the hooks are supposed to be for? I found them very useful for testing during development. One of the patches adds a test module for the ICU hook, and I think that's a valuable place to test regardless of whether any other extension uses the hook. Also, if proper multilib support doesn't land in 16, then the hooks could be a way to build rudimentary multilib support (or at least some kind of ICU version lockdown) until it does land. When Thomas's work is in place, I expect the hooks to change slightly. The hooks are not meant to set any specific API in stone. > =C2=A0 What=20 > other locale libraries are you thinking about using this way?=C2=A0 How > can=20 > we asses whether these interfaces are sufficient for that? I'm not considering any other locale libraries, nor did I see much discussion of that. > =C2=A0 The=20 > refactoring patches don't look convincing just by looking at the > numbers: >=20 > =C2=A0 3 files changed, 406 insertions(+), 247 deletions(-) > =C2=A0 6 files changed, 481 insertions(+), 150 deletions(-) > =C2=A0 12 files changed, 400 insertions(+), 323 deletions(-) The existing code is not great, in my opinion: it doesn't have clear API boundaries, the comments are insufficient, and lots of special cases need to be handled awkwardly by callers. That style is hard to beat when it comes to the raw line count; but it's quite difficult to understand and work on. I think my changes are an improvement, but obviously that depends on the opinion of others who are working in this part of the code. What do you think? --=20 Jeff Davis PostgreSQL Contributor Team - AWS