[Pkg-postgresql-public] Bug#700271: Bug#700271: postgresql-9.1: non-obvious choice of database locale

[Martin Pitt]

Hello Helmut,

Helmut Grohne [2013-02-13  8:49 +0100]:
> Both /etc/default/locale and /etc/environment are empty on the system in
> question.  This likely represents the setting "C" that I usually make
> during installation to avoid translation of messages.

Note that this also means that you cannot use any non-ASCII characters
anywhere, including file names, shell commands, etc. and get a rather
odd-looking date, printer papersize, and whatnot. locale is a lot more
than just translations.

> 
> In fact would postgresql have used my system setting the database
> encoding should have been ASCII, right?

Correct.

> Side question: Is there a way to ask for UTF-8 without translation?

Sure, set LANG=de_DE.UTF-8 and LC_MESSAGES=C . That will still use
UTF-8 character encoding/sorting (LC_CTYPE, LC_COLLATE), and region
settings (LC_PAPER, LC_TIME, LC_PAPER, etc.), but display the plain C
(untranslated) strings.

> I sshed directly into the root account. In this case ssh will take the
> LANG and LC_* variables from the client system, which in this case yes,
> plausibly was responsible for the latin1 choice.

Indeed.

> > As a compromise, pg_createcluster (and thus apt-get install) could
> > show the locale of the generated cluster. Would that help?
> 
> Yes. That would likely have solved the issue in my case, because I would
> have been wondering over latin1 in a database. I think that this
> shouldn't target wheezy though.
> 
> The conclusion appears to be:
> 
> retitle 700271 mention database encoding used during installation
> tags 700271 - wontfix

Agreed, thanks!

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)