From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, AndrewBille(at)gmail(dot)com, michael(at)paquier(dot)xyz |
Subject: | Re: ICU for global collation |
Date: | 2022-09-13 12:41:41 |
Message-ID: | 1f86f120-7b02-68f6-a434-132d054afe33@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13.09.22 07:34, Marina Polyakova wrote:
> 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)
done that way
> Should we change the behaviour of createdb and CREATE DATABASE in
> previous major versions?..
I don't see a need for that.
>> 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...
This is not new behavior in PG15, is it?
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2022-09-13 13:21:22 | Avoid redudant initialization and possible memory leak (src/backend/parser/parse_relation.c) |
Previous Message | Matthias van de Meent | 2022-09-13 12:40:47 | Re: Tuples inserted and deleted by the same transaction |