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?
If we then run a non-MULTIBYTE backend in that database, it will see
the indexes as being out of correct order; this will cause indexscans
to miss values they should find, or perhaps fail outright if the code
happens to detect the inconsistency. If the backend inserts a value
in an index in strcmp() order, the value may be out of place according
to the "yomigana" info, in which case the index is now corrupt from
the point of view of a MULTIBYTE-aware backend as well.
This is essentially the same problem as between LOCALE-aware and
non-LOCALE-aware backends in a database with a non-C locale.
In short, unless you want to enforce a restriction that MULTIBYTE
ordering is always strcmp() order and never anything else, we'd better
disallow non-MULTIBYTE backends in MULTIBYTE databases.
regards, tom lane
