Re: Japanese words not distinguished - Mailing list pgsql-general

From Tom Lane
Subject Re: Japanese words not distinguished
Date
Msg-id 20221.1121187102@sss.pgh.pa.us
Whole thread Raw
In response to Japanese words not distinguished  (Harry Mantheakis <harry@mantheakis.freeserve.co.uk>)
Responses Re: Japanese words not distinguished  (Harry Mantheakis <harry@mantheakis.freeserve.co.uk>)
List pgsql-general
Harry Mantheakis <harry@mantheakis.freeserve.co.uk> writes:
> I run PostgreSQL 7.4.6 on Linux with a JDBC client.

> I initialised my database cluster with the following initdb command:

> initdb --locale=en_GB.UTF-8 --encoding UNICODE

> I have now discovered that my database cannot distinguish Japanese names or
> words - it throws unique constraint errors on a composite primary key that
> includes a VARCHAR field which stores the names or words.

> My tests indicate that the database treats all Japanese names/words as
> equal.

Hmm, is that actually the correct spelling of the locale?  On my Linux
box, locale -a says it's "en_GB.utf8".  I'm not sure how well initdb can
verify the validity of a locale parameter, especially back in the 7.4
branch.  It could be that you are actually using a locale that doesn't
use UTF8 encoding, in which case this behavior is not unheard of
(still pretty broken, IMHO, but I've seen plenty of locale definitions
that just fail on data outside their supported character set).

If you did correctly specify a UTF8-using locale, you probably ought to
report this behavior to your Linux supplier as a bug in that locale
definition.  It doesn't have to sort or case-fold random UTF8 data very
nicely, but it certainly shouldn't report distinct strings as equal.

            regards, tom lane

pgsql-general by date:

Previous
From: "Zlatko Matic"
Date:
Subject: Re: Pb with boolean between MS-Access and PostgreSQl 8.0.3
Next
From: Matt Miller
Date:
Subject: PL/SQL to PLpg/SQL - NO_DATA_FOUND