Kann neue DB nicht in LATIN9 anlegen wenn für DB-Cluster UTF-8 eingestellt ist

[Axel.Rau@…]

Wenn eine bestehende lx-office - Installation mit

$dbcharset = "ISO-8859-15";

auf 2.6 beta 1 aktualisiert wird, gibt es bei einem DB-Cluster mit UTF-8 - Encoding beim Neuanlegen
die Fehlermeldung;

The selected PostgreSQL installation uses UTF-8 as its encoding.
'Therefore you have to configure Lx-Office to use UTF-8 as well.

. Dasselbe passiert auch wenn die DB mittels Pg-upgrade-Skripten aktualisiert werden soll.

In bin/mozilla/admin.pl wird geprüft, ob der cluster mit UTF-8 läuft und falls das zutrifft soll lx-office
auf UTF-8 umgestellt werden. Diese Umstellung ist mit Aufwand verbunden, da für alle lx-office -
Datenbanken eine Backup mit anschließendem Restore mit UTF-8 - Kodierung durchgeführt werden
muß. Den Zeitpunkt der Umstellung sollte man dem Nutzer überlassen.

Kommentiert man in bin/mozilla/admin.pl die Abfrage

if ($cluster_encoding && ($cluster_encoding =~ m/^{(?:UTF-?8|UNICODE)$/i)) {}

aus, dann läuft alles problemlos (mit pgsql 8.2 und 8.3).

Ich denke, eine Warnung mit Erläuterung der nötigen Schritte reicht an dieser Stelle.
Bei einer Neuinstallation sollte man allerdings UTF-8 benutzen (unabhängig von der Vorgabe des
Cluster-Encodings).

Axel

Das Problem ist, dass eine als LATIN9 in einem UTF-8-encodierten Cluster
angelegte Datenbank nicht anständig funktioniert! Die PostgreSQL-Dokumentation
selber sagt dazu folgendes ( ​http://www.postgresql.org/docs/8.3/interactive/
multibyte.html ):

An important restriction, however, is that each database character set must be
compatible with the server's LC_CTYPE setting. When LC_CTYPE is C or POSIX, any
character set is allowed, but for other settings of LC_CTYPE there is only one
character set that will work correctly. Since the LC_CTYPE setting is frozen by
initdb, the apparent flexibility to use different encodings in different
databases of a cluster is more theoretical than real, except when you select C
or POSIX locale (thus disabling any real locale awareness).

In der Tat kann man das auch selber testen. Ich habe hier zwei UTF-8-codierte
PostgreSQL-Cluster, einmal 8.1, einmal 8.2, und darin eine Latin9-codierte
Datenbank angelegt. Wenn ich mich mit der verbinde und einen simplen Test mit
Umlauten mache, so sieht man sofort, dass es nicht klappt:

latin9test=# \l

List of databases

Name | Owner | Encoding

---

latin9test | postgres | LATIN9
template0 | postgres | UTF8
template1 | postgres | UTF8

latin9test=# select upper('ä');

upper

---

ä

(1 row)

latin9test=# select * from test;

id | testtext

---

1 | Eine Ähnlichkeit ist auszuschließen

(1 row)

latin9test=# select * from test where testtext ilike '%ä%';

id | testtext

---

(0 rows)

Da Lx-Office alle Suchanfragen per ILIKE (oder "lower()") stellt, gibt es bei
allen Suchanfragen mit Nicht-ASCII-Zeichen darin Probleme.

Aus genau diesem Grunde verhindert Lx-Office das Anlegen einer Nicht-UTF-8-
Datenbank in einem UTF-8-codierten Cluster.

Dass bei einem Update einer bestehenden Installation bei dieser Situation es
nicht weitergeht ist bedauerlich, und die Fehlermeldung muss angepasst werden.
Die Dokumentation sollte darauf ebenfalls eingehen und beschreiben, wie man die
Datenbank vor dem Upgrade nach UTF-8 konvertiert (pg_dump, iconv, mit psql
einlesen). Den Check selber werde ich aber nicht wieder entfernen.

Danke für die ausführliche Erläuterung.

Wenn ich bei einer Datenbank mit UTF-8 - Kodierung obigen Test mache, klappt es aber auch nicht:

operations=# select lower('Ä');

lower

-------

Ä

Das bedeutet ja vermutlich, daß ich die locale des ganzen clusters von C auf etwas wie de_DE.UTF-8
umstellen müßte, oder?
Danach würde es vermutlich mit der performance des 15GB clusters kläglich aussehen.

Falls diese Einschränkung existiert, sollte man sie dokumentieren.

Die 8.3 release notes sind leider auch nicht sehr hilfreich:

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.

Ist das hier noch aktuell?
Eigentlich ist zum Thema doch alles gesagt, oder?