Re: Names of encodings, lc_collate, lc_ctype - Mailing list pgsql-admin

From Tom Lane
Subject Re: Names of encodings, lc_collate, lc_ctype
Date
Msg-id 810.1562765208@sss.pgh.pa.us
Whole thread Raw
In response to Names of encodings, lc_collate, lc_ctype  (Holger Jakobs <holger@jakobs.com>)
Responses Re: Names of encodings, lc_collate, lc_ctype
Re: Names of encodings, lc_collate, lc_ctype
List pgsql-admin
Holger Jakobs <holger@jakobs.com> writes:
>    CREATE DATABASE db1 WITH TEMPLATE = template0 ENCODING = 'UTF8' 
> LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
> which causes trouble on a PostgreSQL 10 or 11 on an Ubuntu 18.04 machine
>    ungültiger Locale-Name: »en_US.UTF-8«  (meaning 'illegal locale name')

Hmm, does "locale -a" show that you have en_US installed?

It's basically on the platform's libc to say whether the values for
LC_COLLATE and LC_CTYPE are valid.  In my experience, glibc is quite
forgiving about how the encoding suffix is spelled, so I'm wondering
if your destination machine is simply lacking the locale definition.

> The command
>    select * from pg_collation;
> shows (among many others of course)
>    en_US.utf8

This doesn't have anything to do with what CREATE DATABASE accepts,
IIRC.  It does show that when initdb ran, it saw en_US.utf8 reported
by "locale -a"; but maybe that was in a different environment.

> How come there are encodings/collations/locales with and without hyphen? 
> Why does the Ubuntu machine not accept a locale which is present in 
> lc_collation?

Interesting questions, but you need a glibc expert not a Postgres
expert.

            regards, tom lane



pgsql-admin by date:

Previous
From: Holger Jakobs
Date:
Subject: Names of encodings, lc_collate, lc_ctype
Next
From: Ron
Date:
Subject: Re: Names of encodings, lc_collate, lc_ctype