Re: Unicode database on non-unicode operating system

Hi Peter,

Thank you once again. That cleared up a lot of confusion for me and my
co-workers and the next server set up will be with unicode and en_DK.utf8
to ensure consistency.

Regards,
Morten Barklund

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e(at)gmx(dot)net]
Sent: Tuesday, July 15, 2008 3:50 PM
To: pgsql-general(at)postgresql(dot)org
Cc: Morten Barklund
Subject: Re: [GENERAL] Unicode database on non-unicode operating system

Am Dienstag, 15. Juli 2008 schrieb Morten Barklund:
> I can see that lc_collate (sorting) and lc_ctype (lower-upper conversion)
> is set to en_DK and I guess that default encoding for en_DK is iso88591 or
> maybe windows1252.

It is ISO-8859-1. There is no support for Windows charmaps on Linux.

> Thus my server should have been initialized with
> en_DK.utf8 or?

Yes, or you should have chosen a different encoding (LATIN1 in your case) when
creating the database.

> How do I find out what the default encoding for the locale en_DK is?

$ LC_ALL=en_DK locale charmap
ISO-8859-1

Note that this is not the "default" encoding, it is the *only* encoding
supported by that locale.

> I can see, that normally one would sub-specify this by either
> adding .iso88591 or .utf8, but is windows1252 then default?

It might be reasonable to use the .iso88591 or .utf8 suffixes if you want to
be explicit, but the unsuffixed locale name is usually just an alias for one
of these.

> I am not able to reinitdb, as many other databases are running, which might
> be affected negatively. This means, that even though my database is created
> WITH ENCODING 'unicode', it is in fact "broken" as the locale does not
> fully support unicode string handling?

Yes. If you can't reinitdb, then you should recreate the database with
encoding LATIN1. This won't allow all Unicode characters, obviously, but at
least you get proper behavior for the Danish characters that you need.