"Jim Starkey" <jas@...> wrote:

>
> >1) Any long index of charset WIN1251 (binary collation) may become
> >unrestorable as the key will be twice longer.
>
> Why would be key be twice as long? A collation is, in essense, a
> mapping to a byte sequence that compares naturally. That collation
> would map unicode characters back into the WIN1251 character.

Hmm. If we now have:

F CHAR(10) CHARACTER SET WIN1251 COLLATE WIN1251

Would that mean that data is stored in UTF-8 but the index keys are encoded
using WIN1251? Should be the following allowed too:

F CHAR(10) CHARACTER SET UTF-8 COLLATE WIN1251
F CHAR(10) CHARACTER SET UTF-8 COLLATE PXW_CYRL

(as it means the same) ?

> >2) How are you going to maintain compatibility of charset NONE

attachments?

> >
> >
> I anticipate that the API proper will pass only UTF-8 strings but there
> will be client-side layered calls to map to and from specific or
> platform default character sets. I will confess, however, that I
> haven't a clue of what charset NONE is supposed to mean. I don't
> suppose that it means that data types are limited to numbers...

NONE means no charset conversion is applied. You receive what is actually
stored. Most of applications aren't prepared to get UTF-8 here.


Dmitry