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

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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