From: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | invalid multibyte character for locale |
Date: | 2005-02-28 23:07:48 |
Message-ID: | 200503010007.49676.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-patches |
L.S.
I have a database created on:
db=# select version();
version
---------------------------------------------------------------------
PostgreSQL 8.0.1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
(1 row)
The initdb was done using no-locale and unicode as default encoding, the
particular database itself is indeed encoded as UNICODE.
Due to a buggy glibc, the following patch was applied to this install in order
to avoid a crash on things like 'upper(<string>)':
--- oracle_compat.c_orig Mon Dec 6 22:14:11 2004
+++ oracle_compat.c Mon Dec 6 22:14:24 2004
@@ -43,7 +43,7 @@
* We assume if we have these two functions, we have their friends too, and
* can use the wide-character method.
*/
-#if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER)
+#if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER) && FALSE
#define USE_WIDE_UPPER_LOWER
#endif
The database on this machine was dumped and then restored on another, which
has a more recent installation of Slack on it:
db=# select version();
version
------------------------------------------------------------------------
PostgreSQL 8.0.1 on i586-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
(1 row)
Again, the initdb on this machine was done using no-locale and unicode as
default encoding, the particular database obviously is also encoded as
UNICODE.
On the second machine, I'm now getting the following:
db=# select 'JÜTERBOG';
?column?
----------
JÜTERBOG
(1 row)
db=# select lower('JÜTERBOG');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably incompatible with the database
encoding.
As far as I can tell, this didn't happen with v8.0.0, but I'm afraid I can't
be totally sure about that. Obviously, the error doesn't occur on the first
machine due to the hack needed for the buggy glibc.
I'd appreciate a pointer as to what is causing this. It 'shouldn't' be the
hack nor the dump/restore cycle, but.......?
TIA.
--
Best,
Frank.
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Johanson | 2005-02-28 23:10:57 | Re: Possible to run the server with ANSI/ISO string |
Previous Message | Wes | 2005-02-28 23:02:04 | Vacuum time degrading |
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolai Tufar | 2005-02-28 23:22:24 | Thread-safe snprintf() vsnprintf() and printf() |
Previous Message | Bruce Momjian | 2005-02-28 22:41:26 | Re: [PATCHES] snprintf causes regression tests to fail |