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

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

into  moonbone.local:/work/30081-bug-5.1-opt-mysql

command and reported to a client.

The fact that a timestamp field will be set to NO on UPDATE wasn't shown 
by the SHOW COMMAND and reported to a client through connectors. This led to
problems in the ODBC connector and might lead to a user confusion.

A new filed flag called ON_UPDATE_NOW_FLAG is added. 
Constructors of the Field_timestamp set it when a field should be set to NOW
on UPDATE.

The get_schema_column_record function now reports whether a timestamp field
will be set to NOW on UPDATE.

The columns in HAVING can reference the GROUP BY and 
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on 
lower_case_table_names in the same way as the table 
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table 
aliases when requested by lower_case_table_names

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

into  polly.(none):/home/kaa/src/opt/mysql-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/bug30666/my51-bug29131

into  mysql.com:/misc/mysql/31700/51-31700

into  gleb.loc:/home/uchum/5.1-opt

into  mysql.com:/misc/mysql/31700/50-31700

into  mysql.com:/scratch/tnurnberg/31700/51-31700

add 5.1-specific test showing that 'const' access increments 'examined'
counter in slow query log.

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

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

into  polly.(none):/home/kaa/src/opt/mysql-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

After adding an index the <VARBINARY> IN (SELECT <BINARY> ...)
clause returned a wrong result: the VARBINARY value was illegally padded
with zero bytes to the length of the BINARY column for the index search.
(<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.

into  polly.(none):/home/kaa/src/opt/bug32202/my51-bug26215

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

into  mysql.com:/misc/mysql/31700/50-31700

into  mysql.com:/misc/mysql/31700/51-31700

UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.

The patch increases these counters in this special case.

NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."

No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).

into  mysql.com:/misc/mysql/31800/51-31800

into  mysql.com:/scratch/tnurnberg/31800/50-31800

into  mysql.com:/misc/mysql/31800/51-31800

BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME
in comparisons than greater-than and less-than were. ChangeSet makes < >
comparisons similarly robust with regard to trailing garbage (" GMT-1")
and "missing" leading zeros. Now all three comparators behave similarly
in that they throw a warning for "junk" at the end of the data, but then
proceed anyway if possible. Before < > fell back on a string- (rather than
date-) comparison when a warning-condition was raised in the string-to-date
conversion. Now the fallback only happens on actual errors, while warning-
conditions still result in a warning being to delivered to the client.

into  mysql.com:/misc/mysql/31990/51-31990

into  mysql.com:/misc/mysql/31990/50-31990

into  mysql.com:/misc/mysql/31990/51-31990

The bug is a regression introduced by the fix for bug30596. The problem
was that in cases when groups in GROUP BY correspond to only one row,
and there is ORDER BY, the GROUP BY was removed and the ORDER BY
rewritten to ORDER BY <group_by_columns> without checking if the
columns in GROUP BY and ORDER BY are compatible. This led to
incorrect ordering of the result set as it was sorted using the
GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers
from ORDER BY even if its columns were compatible with the GROUP BY
ones.

This patch fixes the regression by checking if ORDER BY columns form a
prefix of the GROUP BY ones, and rewriting ORDER BY only in that case,
preserving the ASC/DESC modifiers. That check is sufficient, since the
GROUP BY columns contain a unique index.

into  polly.(none):/home/kaa/src/opt/mysql-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/bug32020/my51-bug31445