Re: UTF-8 and LIKE vs =

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: rees(at)ddcom(dot)co(dot)jp
Cc: david(at)kineticode(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: UTF-8 and LIKE vs =
Date: 2004-08-25 02:21:32
Message-ID: 20040825.112132.08316551.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> > > I'm not sure what the settings would be, or if it's fully funtional
> > > yet.
> > > Maybe Tatsuo would know? (Hope he doesn't mind me CC-ing him.)
> > >
> > > So, what was the original language and text of the queries you started
> > > this thread with?
> >
> > Korean, but the database I was using has data in 10 different languages
> > in it, making any locale-specific collation useless.

I don't know exactly what kind of encodings you wish to use, but I
think MULE_INTERNAL might help you. It's actually mixture of various
encodings with encoding-prefix added to each letter. For example if
you can mix KS5601 (Korean) and Japanese Kanji (JIS X0208) in a *same*
column. So if you don't have problem with sorting KS5601/JIS X0208
with C locale, you should not have problem with MULE_INTERNAL too in
theory.

Remaining problem is how to display the Korean-Japanese mixed string
in your client, but this is not PostgreSQL's problem, of
course. However you could write your own conversion function
MULE_INTERNAL <--> UTF-8, and might be able to solve the problem.
--
Tatsuo Ishii

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nick 2004-08-25 03:02:16 Substring RegExp Extract path
Previous Message Joel 2004-08-25 02:10:09 Re: UTF-8 and LIKE vs =