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 1p2tAh-0006w2-Pd for pgsql-bugs@arkaria.postgresql.org; Wed, 07 Dec 2022 12:05:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p2tAg-0005E6-8X for pgsql-bugs@arkaria.postgresql.org; Wed, 07 Dec 2022 12:05:06 +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 1p2tAf-0005Cd-Vj for pgsql-bugs@lists.postgresql.org; Wed, 07 Dec 2022 12:05:05 +0000 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2tAa-0000yG-JS for pgsql-bugs@lists.postgresql.org; Wed, 07 Dec 2022 12:05:04 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id BE8C12B068E7; Wed, 7 Dec 2022 07:04:57 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 07 Dec 2022 07:04:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1670414697; x= 1670421897; bh=Dw3win1U98AZfkiNeQfY0i4wQl63EIj1zghGs84VKLc=; b=q jfpp2UCDppdxFkoFBiKKePYWNnmL1FHnIEEi8xdbcNdBi5vfkD+c+kFvOUExyP3b WsHUtTvkil+vcs0T3ihUgIUVxS4oho/cIinw/MrHdeAiTOmnKFNkP2Cy58G19gZX MhrZyPRq8PITDWHedFV1s+dRQHZ0cBJgeMGBphaOb0ThoeycjbqEKdfVjTwi2wf1 lCxHQdKoOT7Pszcx14hSzicQW7C5XcbOoa0ELbzWTyBkGEksngRjhtzOuB6fU6/s P6SICJVwhcbXzNvYgq1Q19Znai+w9ytKl3tORDMx7iRuya2RkemD2Oxk9ObZFYrQ WD9S02tPlvagmM/gU+Vrg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudekgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepheelffeggedujeetiefh leetuddvieffhfffvdejvdffgeejkeduleduheduieefnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Dec 2022 07:04:56 -0500 (EST) Message-ID: <428169fe-2eb3-4415-a5be-6f59112f26b2@enterprisedb.com> Date: Wed, 7 Dec 2022 13:04:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: CREATE COLLATION without LOCALE throws error in v15 Content-Language: en-US To: Jeff Davis , Kyle Spearrin , pgsql-bugs@lists.postgresql.org Cc: Justin Baur , Vince Grassia References: <7b99b4a7fc5284008bae32b77a776d25b4a400bc.camel@j-davis.com> From: Peter Eisentraut In-Reply-To: <7b99b4a7fc5284008bae32b77a776d25b4a400bc.camel@j-davis.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 07.12.22 00:57, Jeff Davis wrote: > On Fri, 2022-12-02 at 14:14 -0500, Kyle Spearrin wrote: >> However, in Postgres 15 we see the following error: >> >> ERROR: parameter "locale" must be specified > > I agree that this is some kind of bug. The docs seem pretty clear[1]: > > "locale > > This is a shortcut for setting LC_COLLATE and LC_CTYPE > at once. If you specify this, you cannot specify either > of those parameters." > > The error appears to come from commit f2553d4306 ("Add option to use > ICU as global locale provider"). My guess is that it was seen as > clearer to write LOCALE, and that the error wasn't expected to cause > anyone a problem. This was an intentional change because of underlying conceptual and catalog changes. lc_collate, lc_ctype, and iculocale are now tracked separately in the catalogs. This is also important because for a database they actually are used separately. So this also keeps the locale/collation settings for databases and collations consistent. The "locale" parameter is now basically "default for whatever settings are appropriate for the locale provider". We should change the documentation in that direction.