Could anybody give an insight on the locale and numeric types behaviour in PostgreSQL? We work with Italian locale. That is comma separation for decimal part. Setting in postgresql.conf
# These settings are initialized by initdb, but they can be changed.
lc_messages = 'it_IT.UTF-8' # locale for system error message
# strings
lc_monetary = 'it_IT.UTF-8' # locale for monetary formatting
lc_numeric = 'it_IT.UTF-8' # locale for number formatting
lc_time = 'it_IT.UTF-8' # locale for time formatting
.. does nothing! It behaves in a quite appropriate way with dates and so, BUT the numeric type remains DOT separated for decimal part.
root#server:~# uname -a
Linux server 2.6.32-36-generic-pae #79-Ubuntu SMP Tue Nov 8 23:25:26 UTC 2011 i686 GNU/Linux
root#server:~# dpkg -l | grep postgresql
ii postgresql-8.4 8.4.9-0ubuntu0.10.04 object-relational SQL database, version 8.4
ii postgresql-client 8.4.9-0ubuntu0.10.04 front-end programs for PostgreSQL (supported)
EDIT
Having problem with implementation of locale in different scopes: db, server script, os and client side. Decided to avoid any locale formatting and use en_EN locale. The locale formatting will be applied only at the moment of output and so.
I quote the manual:
lc_numeric (string)
Sets the locale to use for formatting numbers, for example with the to_char family of functions.
Concerns these type formatting functions. You should be able to reproduce the following demo:
SHOW lc_numeric;
de_AT.UTF-8
SELECT to_number('13,4','999D99')
13.4
SELECT to_char(13.4,'FM999D99')
13,4
SET lc_numeric = 'C';
SELECT to_number('13,4','999D99')
134
SELECT to_char(13.4,'FM999D99')
13.4
RESET lc_numeric;
Template patterns in the manual.
The format of numbers in SQL expressions does not change with locale settings. That would be madness.
On a different note: you are aware that you have to (at least) reload the server after changing postgresql.conf.
pg_ctl reload
Related
As this might have something to do with AWS Lightsail, I've cross posted this question on AWS - Click Here
I'm trying to create a template database using
CREATE DATABASE __edgedbtpl__ OWNER='edgedb' IS_TEMPLATE = TRUE TEMPLATE='template0' ENCODING='UTF8' LC_COLLATE='C' LC_CTYPE='C.UTF-8';
But this fails and gives me the error
ERROR: invalid locale name: "C.UTF-8"
I checked if the PostgreSQL server supports the C.UTF-8 locale, using
SELECT collname FROM pg_collation WHERE lower(replace(collname, '-', '')) = 'c.utf8' LIMIT 1;
which gives me the response
collname
----------
C.utf8
(1 row)
Question
How are the collnames in pg_collation different from SHOW LC_CTYPE and SHOW LC_COLLATE?
SHOW LC_COLLATE and SHOW LC_TYPE responded with en_US.UTF-8 and not C.UTF-8. So how should I identify if a certain locale is supported?
Collation names are identifiers, not string literals in PostgreSQL. Use double quotes instead of single quotes. Also, case and spelling matter, so use "C.utf8".
I want to use an ICU system-insensitive sorting collation, to avoid sorting differences between postgres11-on-mac vs postgres11-on-Ubuntu. My first test was to dump out my existing Collate=en_US.UTF-8 and pg_restore them into a db created with Collate=en-US-x-icu
Create Database doc has this to say:
To create a database music with a different locale:
CREATE DATABASE music
LC_COLLATE 'sv_SE.utf8' LC_CTYPE 'sv_SE.utf8'
TEMPLATE template0;
I seem to have the required icu locales already:
select collname, collprovider from pg_collation where collname like 'en_US%';
collname | collprovider
------------------------+--------------
en_US.UTF-8 | c
en_US | c
en_US.ISO8859-15 | c
en_US.ISO8859-1 | c
en_US | c
en_US | c
en-US-x-icu | i 👈
en-US-u-va-posix-x-icu | i 👈
(8 rows)
But no luck when creating a database with either icu locales.
CREATE DATABASE test LC_COLLATE = 'en-US-x-icu' TEMPLATE template0;
ksysdb=# CREATE DATABASE test LC_COLLATE = 'en-US-x-icu' TEMPLATE template0;
ERROR: invalid locale name: "en-US-x-icu"
I can use LC_COLLATE with other locales:
The LC_COLLATE clause does seem to come with some strings attached, such as watching your encoding and specifying an appropriate template. But it seems to give error hints w non-ICU locales.
This works, for example: CREATE DATABASE test LC_COLLATE = 'en_US' TEMPLATE template0;
and this one gives a helpful user message:
ksysdb=# CREATE DATABASE test LC_COLLATE = 'en_US.ISO8859-15' TEMPLATE template0;
ERROR: encoding "UTF8" does not match locale "en_US.ISO8859-15"
DETAIL: The chosen LC_COLLATE setting requires encoding "LATIN9".
Note: a related question, PostgreSQL 10 on Linux - LC_COLLATE locale en_US.utf-8 not valid, doesn't seem all that relevant, as the answer talks about generating an OS-level locale to fix the issue. While the ICU locales, as far as I understand, are expressly intended to be separated from the underlying OS.
How can I output the result of PostgreSQL dates function as to_char to french language, for example the output of:
select to_char(current_date, 'Day') ;
should be (a french name for a day):
Mardi
instead of english of day (e.g. Monady)
You would need to set the display of date/time (LC_TIME) to french, and to query not the Day but rather the localizable day TMDay using the TM prefix.
show LC_TIME;
SET LC_TIME = 'French';
select to_char(current_date, 'TMDay') ;
to_char
---------
Mardi
(1 row)
The following works on Ubuntu 16.04 Server, with english language set-up
first we need to add system support for French templating with the command:
sudo locale-gen fr_FR.utf8
then restart postgresql service:
sudo systemctl restart postgresql
then log in to psql
SET LC_TIME = 'fr_FR.utf8';
select to_char(current_date, 'TMDay') ;
to_char
---------
Mardi
(1 row)
Desciption of the issue is given at link. It seems that it is a PostgreSQL bug only. To resolve this issue, there seems to be only a single workaround, which is to create a list of locale (map) with key as <Language>_<Country>.<CodePage>and value as <Language>, <Country>.
For example:
English_United States.1252 = English, United States
...
Since value of parameter --locale is accepted in the format of <Language>, <Country>whereas output of command SHOW LC_COLLATE is in the format of <Language>_<Country>.<CodePage>. So, during an ugrade I will get the value of lc_collate cmd and get the corresponding value from the list and provide it during PostgreSQL 9.5 installation.
How do I convert <Language>_<Country>.<CodePage> to appropriate format for successful installation ?
After an upgrade from Ubuntu Server 14.04 to 16.04 I had to also upgrade my Postgres clusters from 9.3 to 9.5. The normal way to do that is to first drop the (empty) 9.5 cluster that the upgrade created:
# pg_dropcluster 9.5 main
and then to upgrade the old 9.3 cluster to 9.5:
# pg_upgradecluster 9.3 main
This however results in an error:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US.UTF-8",
LC_ALL = (unset),
LC_PAPER = "nl_NL.UTF-8",
LC_ADDRESS = "nl_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_NUMERIC = "nl_NL.UTF-8",
LC_TELEPHONE = "nl_NL.UTF-8",
LC_IDENTIFICATION = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LC_TIME = "nl_NL.UTF-8",
LC_NAME = "nl_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Error: The locale requested by the environment is invalid.
Error: Could not create target cluster
This means I could not upgrade to Postgres 9.5.
I checked all locale settings:
the en_US.UTF-8 locale exists and is properly generated as checked with locale -a (it shows en_US.utf8 in its list)
The file /etc/environment contains LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8
/etc/default/locale contains the same setting for LANG, LANGUAGE and LC_ALL
I can start Perl without any issue using "perl -e exit"
The error message is generated from the pg_createcluster script which is called from pg_updatecluster. But running pg_createcluster from the command line works just fine, without any issue.
Workaround for the issue:
I used the following workaround to at least get the conversion to work. I edited the /usr/bin/pg_upgradecluster script, as follows:
Find the code where it calls pg_createcluster by looking for the comment "create new cluster"
That code consists of a series of "push" statements, ending in the suspicious line:
delete $ENV{'LC_ALL'}
Notice that this LC_ALL is exactly the variable that is unset in the error message.
Comment out that delete comment by adding a '#' before it, then save.
This at least circumvents this problem and lets you run the upgrade.
My question: is this a bug in the pg_upgradecluster script, or is something else awry on my system?
had the same problem on an ubuntu 16.04 server. what helped in my case was to generate all the locales that appear in your listing of $ locale:
$ sudo locale-gen "en_US.UTF-8"
$ sudo locale-gen "nl_NL.UTF-8"
good luck!
In my case, it was complaining about
Error: The locale requested by the environment is invalid:
LANG: en_GB
LANGUAGE: en_GB:en
So I unset LANG and unset LANGUAGE and it worked.
For me, I have followed many suggestions and still didn't work.
The script mentioned
LC_TIME=en_UK but it's totally unrelated so I ignored it at first.
Turns out this was the problem and doing "unset LC_TIME" was all I needed.
Posting here in case it happened to someone else.
My quick way to disable that message: (macOS 12 Monterey M1)
Open Terminal -> Preferences -> Advanced tab -> uncheck to Set locale environment variables on startup
Just came across this in fresh Ubuntu + PostgresQL install, after all those years.. either way, the solution is:
apt-get install locales