Re: bk commit into 5.0 tree (igreenhoe:1.2272) BUG#19342

[Ian Greenhoe]

On Thu, 2006-09-14 at 20:33 +0300, Sergey Petrunia wrote:
> Hi Ian,
> 
> On Tue, Sep 12, 2006 at 11:18:06PM -0700, Ian Greenhoe wrote:
> > Below is the list of changes that have just been committed into a local
> > 5.0 repository of greenman. When greenman does a push these changes will
> > be propagated to the main repository and, within 24 hours after the
> > push, to the public repository.
> > For information on how to access the public repository
> > see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
> > 
> > ChangeSet@stripped, 2006-09-12 23:17:58-07:00,
> igreenhoe@stripped +4 -0
> >   Fix for bug #19342 (IN works incorrectly for BIGINT UNSIGNED values)
> >   
> >   Problem: the in function extracts and stores the integer portion of
> >   an integer-valued Item prior to comparison for speed.  However, this
> >   extraction did not keep track if the value was unsigned in certian
> >   circumstances, and assumed that the stored value was signed.
> >   
> >   Solution: add the extra information so that we can make the
> >   determination at comparison time if the origional values were
> >   signed or not.  Note that this may appear to be an inefficent packing
> >   of the data; however, it ensures that the long longs are
> >   word-aligned, and also keeps the signedness bit near the value so
> >   that we can efficently sort.
> > 
> 
> > --- 1.22/mysql-test/t/func_in.test	2006-09-12 23:18:06 -07:00
> > +++ 1.23/mysql-test/t/func_in.test	2006-09-12 23:18:06 -07:00
> > @@ -232,3 +232,21 @@
> >  select some_id from t1 where some_id not in(-4,-1,-4);
> >  select some_id from t1 where some_id not in(-4,-1,3423534,2342342);
> >  drop table t1;
> > +
> > +# bug 19342: IN works incorrectly for bigint unsigned values
> > +create table t1 (c1 bigint unsigned);
> > +insert into t1 values (0xFFFFFFFFFFFFFFFF);
> > +select * from t1 where c1=-1 or c1=-2;
> > +select * from t1 where c1 in (-1, -2);
> > +drop table t1;
> > +
> > +create table t1 (c1 smallint(5));
> > +insert into t1 values (1),(2),(3),(4),(5),(-1),(-2);
> > +
> > +select * from t1 where c1 in (18446744073709551615,18446744073709551612);
> > +select * from t1 where c1 not in (18446744073709551615,18446744073709551612);
> > +select c1 from t1 where c1 in (1,3);
> > +select c1 from t1 where c1 not in (1,3);
> > +
> > +drop table t1;
> Could you please also add testcases that use 'range' access method? Range
> optimizer code in opt_range.cc gives special treatment to [NOT] IN and it
> would be interesting to find out whether that part of the code treats BIGINT
> UNSIGNED values correctly :-)

OK, will do.

-Ian