Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?
От | Tatsuo Ishii |
---|---|
Тема | Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database? |
Дата | |
Msg-id | 20010215235800Y.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?
|
Список | 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 по дате отправления: