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?
|
Список | 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 по дате отправления: