Re: Names of encodings, lc_collate, lc_ctype
От | Holger Jakobs |
---|---|
Тема | Re: Names of encodings, lc_collate, lc_ctype |
Дата | |
Msg-id | bdb6898d-2c8b-3604-dc5a-f5e52823a34f@jakobs.com обсуждение исходный текст |
Ответ на | Re: Names of encodings, lc_collate, lc_ctype (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
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@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.utf8This 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@jakobs.com
+49 178 9759012 oder +49 2202 817157
В списке pgsql-admin по дате отправления: