Allow spaces in windows service names.

Changed the default Windows service name for mysqld from MySql to MySQL. This should not affect usage, because service names are not case sensitive.

When you install mysqld as a service on Windows systems, mysqld will read startup options in option files from the option group with the same name as the service name. (Except when the service name is MySQL).

Fixed Bug#1335 when filesort was never shown in EXPLAIN if query contained ORDER BY NULL clause.

Fixed invalidation of whole query cache on DROP DATABASE. (Bug#1898)

Fixed bug in range optimizer that caused wrong results for some not likely AND/OR queries. (Bug#1828)

Fixed a crash in ORDER BY when ordering by expression and identifier. (Bug#1945)

Fixed a crash in an open HANDLER when an ALTER TABLE was executed in a different connection. (Bug#1826)

Fixed a bug in trunc* operator of full-text search which sometimes caused MySQL not to find all matched rows.

Fixed bug in zero prepending to DECIMAL column type.

Fixed optimiser bug, introduced in 4.0.16, when REF access plan was preferred to more efficient RANGE on another column.

Fixed problem when installing a MySQL server as a Windows service using a command of the form mysqld --install mysql --defaults-file=path-to-file.

Fixed an incorrect result from a query that uses only const tables (such as one-row tables) and non-constant expression (such as RAND()). (Bug#1271)

Fixed bug when the optimiser did not take SQL_CALC_FOUND_ROWS into account if LIMIT clause was present. (Bug#1274)

mysqlbinlog now asks for a password at the console when the -p or --password option is used with no argument. This is consistent with the way that other clients such mysqladmin and mysqldump already behave. Note: A consequence of this change is that it is no longer possible to invoke mysqlbinlog as mysqlbinlog -p pass_val (with a space between the -p option and the following password value). (Bug#1595)

Bug accidentally introduced in 4.0.16 where the slave SQL thread deleted its replicated temporary tables when STOP SLAVE was issued.

In a ``chain'' replication setup A->B->C, if 2 sessions on A updated temporary tables of the same name at the same time, the binary log of B became incorrect, resulting in C becoming confused. (Bug#1686)

In a ``chain'' replication setup A->B->C, if STOP SLAVE was issued on B while it was replicating a temporary table from A, then when START SLAVE was issued on B, the binary log of B became incorrect, resulting in C becoming confused. (Bug#1240)

When MASTER_LOG_FILE and MASTER_LOG_POS were not specified, CHANGE MASTER used the coordinates of the slave I/O thread to set up replication, which broke replication if the slave SQL thread lagged behind the slave I/O thread. This caused the slave SQL thread to lose some events. The new behaviour is to use the coordinates of the slave SQL thread instead. See Secção 4.11.8.1, “CHANGE MASTER TO”. (Bug#1870)

Now if integer is stored or converted to TIMESTAMP or DATETIME value checks of year, month, day, hour, minute and second ranges are performed and numbers representing illegal timestamps are converted to 0 value. This behaviour is consistent with manual and with behaviour of string to TIMESTAMP/DATETIME conversion. (Bug#1448)

Fixed bug when BIT_AND() and BIT_OR() group functions returned incorrect value if SELECT used a temporary table and no rows were found. (Bug#1790).

BIT_AND() is now unsigned in all contexts. This means that it will now return 18446744073709551615 (= 0xffffffffffffffff) instead of -1 if there were no rows in the result.

Fixed bug with BIT_AND() still returning signed value for an empty set in some cases. (Bug#1972)

Fixed bug with ^ (XOR) and >> (bit shift) still returning signed value in some cases. (Bug#1993)

Replication: a rare race condition in the slave SQL thread, which could lead to a wrong complain that the relay log is corrupted. (Bug#2011)

Replication: if an administrative command on a table (OPTIMIZE TABLE, REPAIR TABLE etc) was run on the slave, this could sometimes stop the slave SQL thread (this did not led to any corruption; one just had to type START SLAVE to get replication going again). (Bug#1858)

Replication: in the slave SQL thread, a multi-table UPDATE could produce a wrong complain that some record was not found in one table, if the UPDATE was preceded by a INSERT ... SELECT. (Bug#1701)