From: Tom Lane <tgl@sss.pgh.pa.us>
To: Holger Jakobs <holger@jakobs.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: Names of encodings, lc_collate, lc_ctype
In-reply-to: <3da4af02269b44a18b56a070af0bca18@jakobs.com>
References: <3da4af02269b44a18b56a070af0bca18@jakobs.com>
Comments: In-reply-to Holger Jakobs <holger@jakobs.com>
	message dated "Wed, 10 Jul 2019 14:20:28 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <809.1562765208.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 10 Jul 2019 09:26:48 -0400
Message-ID: <810.1562765208@sss.pgh.pa.us>
Precedence: bulk

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