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

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

Oh, I see.  So the question still remains: can a MULTIBYTE-aware backend
ever use a sort order different from strcmp() order?  (That is, not as
a result of LOCALE, but just because of the non-SQL-ASCII encoding.)

Actually there are more complicated cases that would depend on more
features of the encoding than just sort order.  Consider
CREATE INDEX fooi ON foo (upper(field1));

Operations involving this index will misbehave if the behavior of
upper() ever differs between MULTIBYTE-aware and non-MULTIBYTE-aware
code.  That seems pretty likely for encodings like LATIN2...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Indexing new type ........