BUG #3924: Create Database with another encoding as the encoding from postgres

Stefan Kunick wrote:

I installed postgres with the encoding 1252. After this, i started the
program createdb (createdb -E LATIN1 -O postgres -p 5555 -U postgres). The
program stopped with the error message: createdb: database creation failed.
Error: encoding LATIN1 does not match server's locale German_Germany.1252
DETAIL: The server's LC_CTYPE setting requires encoding WIN1252.

With the former version 8.2, i can create a database with other encoding

You could, but the result wouldn't have worked correctly. You need to pick
locales and encodings that match. This was always true, but not it is
enforced.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Stefan Kunick wrote:

PostgreSQL version: 8.3RC2
Operating system: Windows Longhorn
Description: Create Database with another encoding as the encoding
from postgres
Details:

I installed postgres with the encoding 1252. After this, i started the
program createdb (createdb -E LATIN1 -O postgres -p 5555 -U postgres). The
program stopped with the error message: createdb: database creation failed.
Error: encoding LATIN1 does not match server's locale German_Germany.1252
DETAIL: The server's LC_CTYPE setting requires encoding WIN1252.

With the former version 8.2, i can create a database with other encoding

Yes, that's an intentional change. From release notes:

Disallow database encodings that are inconsistent with the server's locale setting (Tom)

On most platforms, C locale is the only locale that will work with any database encoding. Other locale settings imply a specific encoding and will misbehave if the database encoding is something different. (Typical symptoms include bogus textual sort order and wrong results from upper() or lower().) The server now rejects attempts to create databases that have an incompatible encoding.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:

Yes, that's an intentional change. From release notes:

I had the same problem this morning. We provide a sample database with
LATIN1 encoding (included in our setup). So how can i change my encoding
to have a database that can be used with PG 8.1; 8.1; 8.2 and 8.3
without problems and without knowing how the server was installed? What
is the required encoding as LATIN1 was the encoding we prefered. We
don't want to use UNICODE.

Regards

Pit

Pit M. wrote:

I had the same problem this morning. We provide a sample database with
LATIN1 encoding (included in our setup). So how can i change my encoding
to have a database that can be used with PG 8.1; 8.1; 8.2 and 8.3
without problems and without knowing how the server was installed? What
is the required encoding as LATIN1 was the encoding we prefered.

How exactly are you providing the sample database? If it's in a pg_dump
format, it should work regardless of the encoding and locale used in initdb.

If you're issuing a CREATE DATABASE command, can't just don't specify
any encoding and let it use the default?

We don't want to use UNICODE.

Why not?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com