Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database? - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?
Date
Msg-id 20010215235800Y.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > If we sort these strings using strcmp(), we would get:
> > ...
> > This result might not be perfect, but resonable for most cases since
> > the code value of each character in EUC_JP is defined in the hope that
> > it can be sorted by its phisical value.
> 
> > If we are not satisfied with this result for some reasons, we could
> > add an auxiliary "yomigana" field to get the correct order (Yomigana
> > is a pronounciation of KANJI).
> 
> Okay, so if a database has been built by a backend that knows MULTIBYTE
> and has some "yomigana" info available, then indexes in text columns
> will not be in the same order that strcmp() would put them in, right?

No. The "yomigana" exists in the application world, not in the
database engine itself. What I was talking about was an idea to add
an extra column to a table.

create table t1 (      kanji text,    -- KANJI field      yomigana    text    -- YOMIGANA field
);

The query would be something like:

select kanji from t1 order by yomigana;
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?
Next
From: Tom Lane
Date:
Subject: Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?