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 1pyfjo-0000dw-Dj for pgsql-hackers@arkaria.postgresql.org; Mon, 15 May 2023 21:28:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pyfYe-0000V4-HX for pgsql-hackers@arkaria.postgresql.org; Mon, 15 May 2023 21:16:40 +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 1pyfYe-0000Uq-1F for pgsql-hackers@lists.postgresql.org; Mon, 15 May 2023 21:16:40 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pyfYY-002YyF-R5 for pgsql-hackers@lists.postgresql.org; Mon, 15 May 2023 21:16:36 +0000 Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-52c6f8ba7e3so12216299a12.3 for ; Mon, 15 May 2023 14:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20221208.gappssmtp.com; s=20221208; t=1684185394; x=1686777394; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=uINmH16pQ0g3H6+JsvP9UsTYYgup+vwy2mUxrqdJT+g=; b=mSrQpKDaYhLD8eIMnNx9mdJyT0aImvBD3BcYPm2PmZn9+mdV10QHDv0F+OAbXt44pP x5CdKplkcTgLl19DP7NwzNAPM1XflMgdD6S6FFWfxRaD331gV/BXLiWdYTsgP4NN++Rm nq+YtK8TAFIDf4w6K/LkhO6v1foXUifenm9BVkVXnLOlkSmZE4vcJncy6jsHHVc4NdGh h6fliZyh0VU0thxgkpR31Fon7XtD2fCAyr2wGpO7kqDScMZiO31np1v7Rj3tuqEA7w2B VGE6p/uFzn2RkVT1tvgb3exZyEIyeRjp1hpwukH/8ZLaixqSlkTRYLJNOQeT1VgAx0Dd 10aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684185394; x=1686777394; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uINmH16pQ0g3H6+JsvP9UsTYYgup+vwy2mUxrqdJT+g=; b=cbvsCl+OMnEGukMS8T/xJr1SnnquVLJvfN/VeZXeZ9dLLcTSuNjQVzC4fOZu9ZVhz4 wf55rbV7GZfp3BrTOfL/CXaUxZB+lx47rdqG1/XYPNcNdsitvIjl3rybQEylHEm5PvgD Ba7gluHchLYaSfJc4OKydXzyrh4C0ZygBp/zRptwT8SCum09NxA12ER+6VWT2acNWjkd AxJc8GbKAZ7GgYzwr2yOHvoHAtnMk56FUCaKN+EFOvnWJxZFxGsg4Q7k6LPlkpqsPko9 W105ofcI6sXZzh5WDV28AHfuRC+/4Abu9qTfPL//k9QgR6ugA8ZX+JCe5KCd2doL3tvn Mf4w== X-Gm-Message-State: AC+VfDw0k1ACbzBFQ62KmLQ2zzGTRKd/2G7BEwpsu8/uKL59YX6nDWGc H3L/nQz8i1YSrr7poQr7b6E/cA== X-Google-Smtp-Source: ACHHUZ4K4ZU+GfVfSHOBhFFASJFbVhPLoQAKa8hQOj5TtaErzIMKW/YUSn9i5YEXJRp0vAfgdpgcyA== X-Received: by 2002:a05:6a20:432b:b0:f8:b39b:b24e with SMTP id h43-20020a056a20432b00b000f8b39bb24emr42271360pzk.11.1684185393876; Mon, 15 May 2023 14:16:33 -0700 (PDT) Received: from [172.24.1.9] ([12.126.244.130]) by smtp.gmail.com with ESMTPSA id z11-20020a65610b000000b00528db73ed70sm11520687pgu.3.2023.05.15.14.16.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 May 2023 14:16:32 -0700 (PDT) Message-ID: <1377eac26650066ebb8923cfa6010de682766f7b.camel@j-davis.com> Subject: Re: Order changes in PG16 since ICU introduction From: Jeff Davis To: Tom Lane Cc: Daniel Verite , Andrew Gierth , Peter Eisentraut , Sandro Santilli , Regina Obe , pgsql-hackers@lists.postgresql.org Date: Mon, 15 May 2023 14:16:31 -0700 In-Reply-To: References: <543e4ce6-8205-4aea-b54b-12b9ef747bf6@manitou-mail.org> <654a49f7ff7461bcf47be4181430678d45f93858.camel@j-davis.com> <37520ec1ae9591f83132f82dbd625f3fc2d69c16.camel@j-davis.com> <483826.1683582475@sss.pgh.pa.us> 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 Mon, 2023-05-08 at 14:59 -0700, Jeff Davis wrote: > The easiest thing to do is revert it for now, and after we sort out > the > memcmp() path for the ICU provider, then I can commit it again (after > that point it would just be code cleanup and should have no > functional > impact). The conversion won't be entirely dead code even after we handle the "C" locale with memcmp(): for a locale like "C.UTF-8", it will still be passed to the collation provider (same as with libc), and in that case, we should still convert that to a language tag consistently across ICU versions. For it to be entirely dead code, we would need to convert any locale with language "C" (e.g. "C.UTF-8") to use the memcmp() path. I'm fine with that, but that's not what the libc provider does today, and perhaps we should be consistent between the two. If we do leave the code in place, we can document that specific "en-US-u-va-posix" locale so that it's not too surprising for users. Regards, Jeff Davis