Hi Tatsuo / Tom,
[TI]
> Apparently your hack does not kill #define USE_WIDE_UPPER_LOWER.
Mmm, I think it does, but mind you, the hack was applied to the first machine
only (since that was the one with the 'original' buggy glibc causing a
postmaster crash when using upper() and stuff), while it
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> BTW, the current code for upper/lower etc. seems to be broken. The
> exact problem you have are happening in Japanese encodings too(EUC_JP)
> too. PostgreSQL should not use wide-character method if LC_CTYPE is C.
Yeah, we came to that same conclusion a fe
Apparently your hack does not kill #define USE_WIDE_UPPER_LOWER.
BTW, the current code for upper/lower etc. seems to be broken. The
exact problem you have are happening in Japanese encodings too(EUC_JP)
too. PostgreSQL should not use wide-character method if LC_CTYPE is C.
--
Tatsuo Ishii
> L.S.
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
Marian POPESCU <[EMAIL PROTECTED]> writes:
> I put up a testcase at
> http://perso.netpratique.fr/softexpert/pgsql/unicodetest.data.gz
After experimenting, the only case in which I could get that failure was
to deliberately force a database encoding incompatible with the locale,
namely initdb wit
Marian POPESCU <[EMAIL PROTECTED]> writes:
> I want to report a bug on PG 8.0 (linux : Fedora Core 3)
> A LIKE '%langage C%' in the WHERE clause of my SELECT statement gives
> "invalid multibyte character for locale" error.
> I thought the bug
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?i
Hi,
I want to report a bug on PG 8.0 (linux : Fedora Core 3)
A LIKE '%langage C%' in the WHERE clause of my SELECT statement gives
"invalid multibyte character for locale" error.
I thought the bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113231 was fixed
and the patch was incorporate
