Gleb,
The patch is good. As we discussed, please remove
"field->type() == type()" from Field_bit::eq().
I have some minor corrections of the English of the comment,
please fix and push.
Timour
> #At file:///work/bzr/5.0-bugteam-37799/
>
> 2661 Gleb Shchepa 2008-08-15
> Bug #37799: SELECT with a BIT column in WHERE clause
> returns unexpected result
>
> If:
> 1. a table has a not nullable BIT column c1 with a length
> shorter than 8 bits and some additional not nullable
> columns c2 etc, and
> 2. the WHERE clause is like: (c1 = constant) AND c2 ...,
> the SELECT query returns unexpected result set.
>
>
> The server stores BIT columns in a tricky way to save disk
> space: if column's bit length is not divisible by 8, the
> server places "uneven" bits among the null bits at the start
Above "uneven" is confusing, basically this is num_bits modulo 8,
right? So maybe "remainder" is a better word.
> of a record. The rest bytes are stored in the record itself,
> and Field::ptr points to these rest bytes.
>
> However if a bit length of the whole column is lesser than 8,
Replace "lesser" with "less".
> there are no rest bytes, and there is nothing to store in
replace "rest" with "remaining"
> the record at a regular place. In this case Field::ptr points
replace "a regular" with "its regular"
> to bytes actually occupied by the next column in a record.
> If both columns (BIT and the next column) are NOT NULL,
> the Field::eq function guesses that this is the same column,
replace "guesses" with "incorrectly deduces"
> so query transformation/equal item elimination code (see
> build_equal_items_for_cond) may mix these columns and damage
> conditions containing references to them.
>
>
> The Field::eq function has been modified to take types of
> comparing columns into account to distinguish between BIT and not
> BIT columns referencing the same bytes in a record.
<cut>
