Re: Names of encodings, lc_collate, lc_ctype

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Tom,

After creating the locale with

  sudo locale-gen en_US.UTF-8

and a restart of the PostgreSQL server, it worked.

Thank you.

Holger Jakobs

Am 10.07.19 um 15:26 schrieb Tom Lane:
Holger Jakobs <holger@xxxxxxxxxx> 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
--

Holger Jakobs, Bergisch Gladbach
instant messaging: xmpp:holger@xxxxxxxxxx
+49 178 9759012 oder +49 2202 817157


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux