into  mysql.com:/home/timka/mysql/src/5.1-merge

into  rurik.mysql.com:/home/igor/mysql-5.1

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.1-new

into  mysql.com:/home/psergey/mysql-5.1-bug18659-pre

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.1-new

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.1-new

into  rurik.mysql.com:/home/igor/dev/mysql-5.1-0

into  rurik.mysql.com:/home/igor/dev/mysql-5.1-0

obtain partition number, call partition_info->get_part_partition_id() when
the table has subpartitions, and get_partition_id() otherwise. (The bug
was that we were always doing the latter)

- move slock bitmask to separate hash list, object living only during query

into mysql.com:C:/cygwin/home/mysqldev/my/mysql-5.1-new

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/BARE/mysql-5.1-new

into  c-4908e253.1238-1-64736c10.cust.bredbandsbolaget.se:/home/pappa/bug13520

into  rurik.mysql.com:/home/igor/dev/mysql-5.1-0

into  mysql.com:/home/alexi/innodb/mysql-5.1-merged

Results changed after the bug fix.

into  c-520ae253.1238-1-64736c10.cust.bredbandsbolaget.se:/home/pappa/bug13520

Multiple equalities were not adjusted after reading constant tables.
It resulted in neglecting good index based methods that could be
used to access of other tables.

into  mysql.com:/home/alexi/innodb/mysql-5.1-merged

into  mysql.com:/home/alexi/innodb/mysql-5.1-merged

 Fixed BUG#15650: DELETE with LEFT JOIN crashes server
 with innodb_locks_unsafe_for_binlog.
 Fixed compilation problem with non-C99 compilers
 in btr0sea.c

into mysql.com:/home/psergey/mysql-5.1-bug18025-r2

into  linux.site:/home/reggie/work/mysql-5.1-bug17631

moved several functions from sql_partition to be member functions

into  mysql.com:/usr/home/bar/mysql-5.1-new

into  mysql.com:/usr/home/bar/mysql-5.1-new

into mysql.com:/home/psergey/mysql-5.1-bug18025-r2

 - Fix typo bug in SEL_ARG::is_singlepoint()
 - In set_up_range_analysis_info(), treat MEDIUMINT as enumerable type just like other integer types

into  mysql.com:/home/timka/mysql/src/5.0-bug-16710

The bug was due to a missed case in the detection of whether an index
can be used for loose scan. More precisely, the range optimizer chose
to use loose index scan for queries for which the condition(s) over
an index key part could not be pushed to the index together with the
loose scan.

As a result, loose index scan was selecting the first row in the
index with a given GROUP BY prefix, and was applying the WHERE
clause after that, while it should have inspected all rows with
the given prefix, and apply the WHERE clause to all of them.

The fix detects and skips such cases.