into  magare.gmz:/home/kgeorge/mysql/work/B32400-5.1-opt

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-opt

  Fix for the bug#31048 for 64bit platforms.
subselect.test, subselect.result:
  Corrected text case for the bug#31048.

into  gleb.loc:/work/bk/5.0-opt

into  magare.gmz:/home/kgeorge/mysql/autopush/B31171-5.1-opt

into  polly.(none):/home/kaa/src/opt/mysql-5.1-opt

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

into  polly.(none):/home/kaa/src/opt/bug32221/my51-bug31445

We do not have any executables in libmysql/release/ anymore.

into  magare.gmz:/home/kgeorge/mysql/autopush/B31171-5.1-opt

into  polly.(none):/home/kaa/src/opt/mysql-5.1-opt

into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt

into  polly.(none):/home/kaa/src/opt/bug32221/my51-bug31445

into  magare.gmz:/home/kgeorge/mysql/autopush/B31171-5.1-opt

                  is_last_prefix <= 0, file .\opt_range.cc.

SELECT ... GROUP BY bit field failed with an assertion if the
bit length of that field was not divisible by 8.

 "Table is already up to date" vs. "OK"

On MacOSX 10.5 when you cast something to "bool"
(the built in C type) it takes values 0 or 1 
instead of 0-255 as it seems to be on older compilers.
Fixed by removing the typecast (not needed).
No test case needed : there are tests that test it.

into  magare.gmz:/home/kgeorge/mysql/work/B30788-5.1-opt

into  magare.gmz:/home/kgeorge/mysql/autopush/B30788-5.0-opt

Index lookup does not always guarantee that we can
simply remove the relevant conditions from the WHERE
clause. Reasons can be e.g. conversion errors, 
partial indexes etc. 
The optimizer was removing these parts of the WHERE 
condition without any further checking.
This leads to "false positives" when using indexes.
Fixed by checking the index reference conditions
(using WHERE) when using indexes with sub-queries.

into  moonbone.local:/work/31048-bug-5.0-opt-mysql

  Additional stack check for the bug#31048.

 only on some occasions

Referencing an element from the SELECT list in a WHERE 
clause is not permitted. The namespace of the WHERE
clause is the table columns only. This was not enforced
correctly when resolving outer references in sub-queries.

Fixed by not allowing references to aliases in a 
sub-query in WHERE.

into  gleb.loc:/work/bk/5.0-opt

8bit escape characters, termination and enclosed characters
were silently ignored by SELECT INTO query, but LOAD DATA INFILE
algorithm is 8bit-clean, so data was corrupted during 
encoding.

into  mysql.com:/home/psergey/mysql-5.1-bug30573

into  mysql.com:/home/hf/work/mysql-5.0-opt

into  mysql.com:/home/hf/work/31868/my50-31868

into  mysql.com:/home/hf/work/31868/my51-31868

into  mysql.com:/home/hf/work/31868/my41-31868

into  mysql.com:/home/hf/work/31868/my51-31868

into  mysql.com:/home/hf/work/31868/my51-31868

The problem: ha_partition::read_range_first() could return a record that is 
outside of the scanned range. If that record happened to be in the next 
subsequent range, it would satisfy the WHERE and appear in the output twice.
(we would get it the second time when scanning the next subsequent range)

Fix: 
Made ha_partition::read_range_first() check if the returned recod is within
the scanned range, like other read_range_first() implementations do.

into  moonbone.local:/work/31048-bug-5.0-opt-mysql

into  moonbone.local:/work/31048-bug-5.0-opt-mysql

into  moonbone.local:/work/30384-bug-5.0-opt-mysql

led to creating corrupted index.

Corrected fix. The new method called prepare2 is added to the select_create
class. As all preparations are done by the select_create::prepare function
it doesn't do anything. Slightly changed algorithm of calling the 
start_bulk_insert function. Now it's called from the select_insert::prepare2
function when the SQL_BUFFER_RESULT flags is set.
The is_bulk_insert_mode flag is removed as it is not needed anymore.