Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group