pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Daniel Verite <daniel@manitou-mail.org>
Cc: AndrewBille@gmail.com
Cc: michael@paquier.xyz
Subject: Re: ICU for global collation
Date: Tue, 13 Sep 2022 08:34:16 +0300
Message-ID: <60facfef2a8d54b227500260e86d823e@postgrespro.ru> (raw)
In-Reply-To: <20220909164625.GN31833@telsasoft.com>
References: <20220628013205.GH19662@telsasoft.com>
	<f385ba25e7f8be427b8c582e5cca7d79@postgrespro.ru>
	<7d74b2d7-7fc6-f55b-3f77-c0e05569b64e@enterprisedb.com>
	<YwRUn4J8+uqlyUYQ@paquier.xyz>
	<7ad26354e75259f59c4a6c6997b8ee32@postgrespro.ru>
	<YwWrVEDpLNGFA4Mq@paquier.xyz>
	<20220824085923.jro5ao2m5b4mdll5@jrouhaud>
	<13468bee-a5b4-65aa-932c-c12584f4458d@enterprisedb.com>
	<Yw4KoBm1mS+2xzIj@paquier.xyz>
	<7c99c132dc9c0ac630e0127f032ac480@postgrespro.ru>
	<20220909164625.GN31833@telsasoft.com>

On 2022-09-09 19:46, Justin Pryzby wrote:
> In pg14:
> |postgres=# create database a LC_COLLATE C LC_CTYPE C LOCALE C;
> |ERROR:  conflicting or redundant options
> |DETAIL:  LOCALE cannot be specified together with LC_COLLATE or 
> LC_CTYPE.
> 
> In pg15:
> |postgres=# create database a LC_COLLATE "en_US.UTF-8" LC_CTYPE
> "en_US.UTF-8" LOCALE "en_US.UTF-8" ;
> |CREATE DATABASE
> 
> f2553d430 actually relaxed the restriction by removing this check:
> 
> -       if (dlocale && (dcollate || dctype))
> -               ereport(ERROR,
> -                               (errcode(ERRCODE_SYNTAX_ERROR),
> -                                errmsg("conflicting or redundant 
> options"),
> -                                errdetail("LOCALE cannot be specified
> together with LC_COLLATE or LC_CTYPE.")));
> 
> But isn't the right fix to do the corresponding thing in createdb
> (relaxing the frontend restriction rather than reverting its relaxation
> in the backend).
> 
> diff --git a/src/bin/scripts/createdb.c b/src/bin/scripts/createdb.c
> index e523e58b218..5b80e56dfd9 100644
> --- a/src/bin/scripts/createdb.c
> +++ b/src/bin/scripts/createdb.c
> @@ -159,15 +159,10 @@ main(int argc, char *argv[])
>  			exit(1);
>  	}
> 
> -	if (locale)
> -	{
> -		if (lc_ctype)
> -			pg_fatal("only one of --locale and --lc-ctype can be specified");
> -		if (lc_collate)
> -			pg_fatal("only one of --locale and --lc-collate can be specified");
> +	if (locale && !lc_ctype)
>  		lc_ctype = locale;
> +	if (locale && !lc_collate)
>  		lc_collate = locale;
> -	}
> 
>  	if (encoding)
>  	{

I agree with you that it is more comfortable and more similar to what 
has already been done in initdb. IMO it would be easier to do it like 
this:

diff --git a/src/bin/scripts/createdb.c b/src/bin/scripts/createdb.c
index 
e523e58b2189275dc603a06324a2f28b0f49d8b7..a1482df3d981a680dd3322052e7c03ddacc8dc26 
100644
--- a/src/bin/scripts/createdb.c
+++ b/src/bin/scripts/createdb.c
@@ -161,12 +161,10 @@ main(int argc, char *argv[])

  	if (locale)
  	{
-		if (lc_ctype)
-			pg_fatal("only one of --locale and --lc-ctype can be specified");
-		if (lc_collate)
-			pg_fatal("only one of --locale and --lc-collate can be specified");
-		lc_ctype = locale;
-		lc_collate = locale;
+		if (!lc_ctype)
+			lc_ctype = locale;
+		if (!lc_collate)
+			lc_collate = locale;
  	}

  	if (encoding)

Should we change the behaviour of createdb and CREATE DATABASE in 
previous major versions?..

> BTW it's somewhat crummy that it uses a string comparison, so if you
> write "UTF8" without a dash, it says this; it took me a few minutes to
> see the difference...
> 
> postgres=# create database a LC_COLLATE "en_US.UTF8" LC_CTYPE
> "en_US.UTF8" LOCALE "en_US.UTF8";
> ERROR:  new collation (en_US.UTF8) is incompatible with the collation
> of the template database (en_US.UTF-8)

Perhaps we could check the locale itself with the function 
normalize_libc_locale_name (collationcmds.c). But ISTM that the current 
check is a safety net in case the function pg_get_encoding_from_locale 
(chklocale.c) returns -1 or PG_SQL_ASCII...

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company





view thread (111+ messages)  latest in thread

Message-ID: <60facfef2a8d54b227500260e86d823e@postgrespro.ru>
Permalink:  ../60facfef2a8d54b227500260e86d823e@postgrespro.ru/
Also on:    postgresql.org/message-id/60facfef2a8d54b227500260e86d823e@postgrespro.ru

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: m.polyakova@postgrespro.ru, pryzby@telsasoft.com, peter.eisentraut@enterprisedb.com, rjuju123@gmail.com, daniel@manitou-mail.org, AndrewBille@gmail.com, michael@paquier.xyz
  Subject: Re: ICU for global collation
  In-Reply-To: <60facfef2a8d54b227500260e86d823e@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox