OK, as noted in the upstream discussion of this problem,
http://archives.postgresql.org/pgsql-bugs/2005-10/msg00233.php
this is something that doesn't seem practical to fix in existing versions of Postgres. For the time being,
running a database with an encoding different from what is implied by the initdb-time LC_CTYPE is just
not a supported configuration. This is not adequately warned against in the 7.4 documentation, but
newer PG releases do have a warning about it.
http://www.postgresql.org/docs/8.0/static/multibyte.html
says:
Important: Although you can specify any encoding you want for a database, it is unwise to choose an
encoding that is not what is expected by the locale you have selected. The LC_COLLATE and LC_CTYPE
settings imply a particular encoding, and locale-dependent operations (such as sorting) are likely to
misinterpret data that is in an incompatible encoding.
Since these locale settings are frozen by initdb, the apparent flexibility to use different encodings in
different databases of a cluster is more theoretical than real. It is likely that these mechanisms will be
revisited in future versions of PostgreSQL.
One way to use multiple encodings safely is to set the locale to C or POSIX during initdb, thus disabling
any real locale awareness.

Note

You need to
log in
before you can comment on or make changes to this bug.