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 1pwOy9-0006eY-B5 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 May 2023 15:09:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pwOy8-0000Yj-41 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 May 2023 15:09:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pwOy7-0000Ya-NY for pgsql-hackers@lists.postgresql.org; Tue, 09 May 2023 15:09:35 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pwOy4-001b3V-OM for pgsql-hackers@lists.postgresql.org; Tue, 09 May 2023 15:09:35 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1ab13da70a3so58595695ad.1 for ; Tue, 09 May 2023 08:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20221208.gappssmtp.com; s=20221208; t=1683644971; x=1686236971; 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=yx9WICxifRaSysbwktsHaqcEezUx1zjjyl1ARCUR/i8=; b=K55HUHMdrNOVdd751fAYqXzue0zoOt2zFwqXdIKPfoS1NfS8ZUx+tN5tHiCf204WiT ig6DIa4r81xhjp1WlnfbMVY9GSoHr6LCAosgyy0w3I3TyGb3DNyxBpqzKKZKETBeyCuU 64gmY5w1gm1OcH7OPX9AgnGNhm3V9HP+8iRfbpFwHocDYUaTr+upp6dWlBTCYEJn7mlN VaXw3pUzgOvnPDw3XYhlgn5zpO2RxU26PRigoZXnNoXptGVXMfoYyDdPfsnKkvcUmGP1 6Zv17DlwMSsCvlqvTS+fp3z6ZAvmbHxB3Dn8c+B8mZLzgFUwxKE7xPmMZaYvL6HbBP64 9OpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683644971; x=1686236971; 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=yx9WICxifRaSysbwktsHaqcEezUx1zjjyl1ARCUR/i8=; b=EcZnflNooF3sS0UZgf/jRqese3X0vUIey1eCg1gh6prE35tVsJljsEovvRSGpQGRFZ DzGbnlFpwMS3ljhkqwP3EjARbGW+i1c4bvENO6lhzFcCiuEHmu6iiSqFxwiQyMpQFaMt RpGKuDIC/itVzGFbt041KGKcQsD9gq3qwTXluQaCA7Y+DXBQlQwDmT0v3QCLkzKDfZf1 pq3WPiK/UMp5+z6UetqQEZe04pcL0XfxKLcU6AaIhPYN29HOMS4Nv5vZh8meyj0vIxO+ PObYGvKPaukXt/G7NT+8MvCspDWhakzGWoOoyqp7AadnfXrxMm/kfg67uTqfgK8tLMbG RmXA== X-Gm-Message-State: AC+VfDzSWgmCRs1HmE/7OHj1WAp66A8M3gs4ODlXzb3m35Gz8eSpsqsa TRuNYWBI90MOI0ErAbNHHleSMg== X-Google-Smtp-Source: ACHHUZ4DIvWrIsPWK9/DNZ2wrL3cw+wqQJWo1A4DjpHB91bgYr2iSuTYFYSEV9ny667AwLrSldoInA== X-Received: by 2002:a17:902:6944:b0:1ac:4163:317 with SMTP id k4-20020a170902694400b001ac41630317mr13268617plt.39.1683644970796; Tue, 09 May 2023 08:09:30 -0700 (PDT) Received: from jeff-laptop.lan (c-73-170-46-202.hsd1.ca.comcast.net. [73.170.46.202]) by smtp.gmail.com with ESMTPSA id bj11-20020a170902850b00b001a2135e7eabsm1732957plb.16.2023.05.09.08.09.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 May 2023 08:09:30 -0700 (PDT) Message-ID: <3a00d1f05299d381dc701d283f95d845c741c6a1.camel@j-davis.com> Subject: Re: Order changes in PG16 since ICU introduction From: Jeff Davis To: Alvaro Herrera , Peter Eisentraut Cc: Sandro Santilli , Tom Lane , Regina Obe , pgsql-hackers@lists.postgresql.org Date: Tue, 09 May 2023 08:09:29 -0700 In-Reply-To: <20230509082553.yjikrxn54mi6hezc@alvherre.pgsql> References: <20230509082553.yjikrxn54mi6hezc@alvherre.pgsql> 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 Tue, 2023-05-09 at 10:25 +0200, Alvaro Herrera wrote: > I agree with removing these in v16, since they are going to become > more > meaningless and confusing. Agreed, but it would be nice to have an alternative that does the right thing. It's awkward for a user to read pg_database.datlocprovider, then depending on that, either look in datcollate or daticulocale. (It's awkward in the code, too.) Maybe some built-in function that returns a tuple of the default provider, the locale, and the version? Or should we also output the ctype somehow (which affects the results of upper()/lower())? Regards, Jeff Davis