Oops, I just sent a response to your previous email. You are too quick!
Sergei Golubchik <serg@stripped> wrote on 05/20/2009 02:44:22 PM:
> Hi, Timothy!
>
> On May 20, Timothy P Clark wrote:
> > >
> > > records_in_range is meant to ask how many keys there is between two
> > > different keys.
> > >
> > > There shouldn't be a different answer if the user would ask for
> > >
> > > 'LIKE "ABC%"' or BETWEEN "ABC\0" AND "ABC\FF"
> > >
> > My original post probably wasn't clear, but it's the second format
> > that is giving us trouble. In some cases, that \FF (i.e.
> > max_sort_char) is not a valid (i.e. convertable) character for a given
> > character set (e.g. cp932), and this causes DB2 to complain when the
> > \FF comes through records_in_range.
>
> Just trying to clarify.
>
> Are you saying that for LIKE "ABC%" you get "ABC\FF" in
> records_in_range() even in character sets where \FF is not a valid
> character ?
Yes, that is what I see.
create table t2 (c char(10) collate cp932_ci, index(c));
insert into t2 values("a"),("b"),("c");
select * from t2 force index (c) where c like "a%";
records_in_range shows a min_key of 0x0061000000...
and a max_key of 0x0061FFFFFFF...
But iconv doesn't think that 0xFF is a valid character in cp932, and from
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
I don't see any definition for either 0xFF or 0xFFFF in cp932.
>
> If yes - it must be a bug, both range ends must be valid strings in
> their character set.
>
> Or is the problem in different definitions of cp932 in MySQL and DB2 ?
Thanks,
Tim
