storage engine system variables was not validated and
unexpected value was assigned.

The check_func_enum function used subtraction from the uint
value with the probably negative result. That result of
type uint was compared with 0 after casting to signed long
type. On architectures where long type is longer than int
type the result of comparison was unexpected.


storage/example/ha_example.cc:
  Fixed bug #32034.
  Sample system variable example_enum_var has been added to the
  EXAMPLE storage to test ENUM variables.
sql/sql_plugin.cc:
  Fixed bug #32034.
  The check_func_enum function used subtraction from the uint
  value with the probably negative result. That result of
  type uint was compared with 0 after casting to signed long
  type. On architectures where long type is longer than int
  type the result of comparison was unexpected.
  
  uint value has been casted to long type before subtraction.
mysql-test/t/plugin.test:
  Added test case for bug #32034.
mysql-test/r/plugin.result:
  Added test case for bug #32034.

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


mysql-test/r/partition.result:
  Auto merged
mysql-test/t/partition.test:
  Auto merged

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

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


client/mysql.cc:
  Auto merged
mysql-test/r/information_schema.result:
  Auto merged
mysql-test/r/log_tables.result:
  Auto merged
mysql-test/t/information_schema.test:
  Auto merged
sql/sql_show.cc:
  Auto merged

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.


mysql-test/t/information_schema.test:
  A test case adjusted after fixing the bug#30081.
mysql-test/r/type_timestamp.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/type_ranges.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/show_check.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/ps_5merge.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/ps_4heap.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/ps_3innodb.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/ps_2myisam.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/metadata.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/log_tables.result:
  Adjusted a test case after fixing bug#30081.
mysql-test/r/information_schema.result:
  A test case adjusted after fixing the bug#30081.
mysql-test/r/grant.result:
  Adjusted a test case after fixing bug#30081.
tests/mysql_client_test.c:
  A test case adjusted after fixing the bug#30081.
sql/sql_show.cc:
  Bug#30081: "ON UPDATE CURRENT_TIMESTAMP" wasn't shown by the SHOW FIELDS
  command and reported to a client.
  The get_schema_column_record function now reports whether a timestamp field
  will be set to NOW on UPDATE.
sql/field.cc:
  Bug#30081: "ON UPDATE CURRENT_TIMESTAMP" wasn't shown by the SHOW FIELDS
  command and reported to a client.
  Constructors of the Field_timestamp set the ON_UPDATE_NOW_FLAG on a field when
  it should be set to NOW on UPDATE.
include/mysql_com.h:
  Bug#30081: "ON UPDATE CURRENT_TIMESTAMP" wasn't shown by the SHOW FIELDS
  command and reported to a client.
  A new filed flag called ON_UPDATE_NOW_FLAG  is added.
client/mysql.cc:
  Bug#30081: "ON UPDATE CURRENT_TIMESTAMP" wasn't shown by the SHOW FIELDS
  command and reported to a client.
  The fieldflag2str function is adjusted to print the ON_UPDATE_NOW_FLAG.

mysql-test/r/partition_innodb.result:
  result fixed
mysql-test/t/partition_innodb.test:
  number of subpartitions fixed

Partition handler fails updating tables with partitioning
based on timestamp field, as it calculates the timestamp field
AFTER it calculates the number of partition of a record.

Fixed by adding timestamp_field->set_time() call and disabling
such consequent calls


mysql-test/r/partition.result:
  Bug #32067 Partitions: crash with timestamp column.
  
  test result
mysql-test/t/partition.test:
  Bug #32067 Partitions: crash with timestamp column.
  
  test case
sql/ha_partition.cc:
  Bug #32067 Partitions: crash with timestamp column.
  
  do timestamp_field->set_time() in the ha_partition::update_row()

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

mysql-test/r/partition.result:
  test result fixed
mysql-test/r/partition_innodb.result:
  test result fixed
mysql-test/t/partition.test:
  test moved to partition_innodb
mysql-test/t/partition_innodb.test:
  test moved from partition.test

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


mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged
sql/sql_select.cc:
  Auto merged

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


sql/sql_select.cc:
  Auto merged
mysql-test/r/select.result:
  Manual merge.
mysql-test/t/select.test:
  Manual merge.

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


sql/sql_select.cc:
  Auto merged
mysql-test/r/select.result:
  Manual merge.
mysql-test/t/select.test:
  Manual merge.

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


BitKeeper/etc/ignore:
  auto-union
storage/myisam/mi_dynrec.c:
  Auto merged

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


BitKeeper/etc/ignore:
  auto-union
myisam/mi_dynrec.c:
  Auto merged

When we insert a record into MYISAM table which is almost 'full',
we first write record data in the free space inside a file, and then
check if we have enough space after the end of the file.
So if we don't have the space, table will left corrupted.
Similar error also happens when we updata MYISAM tables.

Fixed by modifying write_dynamic_record and update_dynamic_record functions
to check for free space before writing parts of a record


BitKeeper/etc/ignore:
  Added libmysql_r/client_settings.h libmysqld/ha_blackhole.cc to the ignore list
myisam/mi_dynrec.c:
  Bug #31305 myisam tables crash when they are near capacity.
  
  now we check space left in table in write_dynamic_record
  and update_dynamic_record functions.
  If we don't have enough room for the new (updated) record, return with the
  error.
mysql-test/r/almost_full.result:
  New BitKeeper file ``mysql-test/r/almost_full.result''
mysql-test/t/almost_full.test:
  New BitKeeper file ``mysql-test/t/almost_full.test''

into  polly.(none):/home/kaa/src/opt/bug30666/my51-bug29131


mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged
sql/sql_select.cc:
  Auto merged

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

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


sql/item.cc:
  Auto merged
sql/item.h:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_subselect.cc:
  Auto merged
sql/sp_rcontext.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
mysql-test/r/subselect.result:
  Merge with 5.0-opt.
mysql-test/t/subselect.test:
  Merge with 5.0-opt.

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


sql/sql_select.cc:
  Auto merged

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


sql/sql_select.cc:
  Auto merged

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


mysql-test/r/log_tables.result:
  5.1-only test showing that 'const' access increments counters
mysql-test/t/log_tables.test:
  5.1-only test showing that 'const' access increments counters

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

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


sql/item_cmpfunc.cc:
  Auto merged

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


mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged
sql/sql_select.cc:
  Auto merged

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


sql/sql_select.cc:
  Auto merged

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


sql/sql_select.cc:
  Auto merged

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.


sql/item.cc:
  Fixed bug #28076.
  The Item_cache_str::save_in_field method has been overloaded
  to check cached values for an illegal padding before the saving
  into a field.
sql/item.h:
  Fixed bug #28076.
  The Item_cache_str::is_varbinary flag has been added and the
  Item_cache_str::save_in_field method has been overloaded to prevent
  cached values from an illegal padding when saving in fields.
  The signature of the Item_cache::get_cache method has been
  changed to accept pointers to Item instead of Item_result
  values.
sql/item_cmpfunc.cc:
  Fixed bug #28076.
  The Item_in_optimizer::fix_left method has been modified to
  to call Item_cache::get_cache in a new manner.
sql/item_subselect.cc:
  Fixed bug #28076.
  The subselect_indexsubquery_engine::exec method has been
  modified to take into account field conversion errors
  (copy&paste from subselect_uniquesubquery_engine::exec).
sql/sp_rcontext.cc:
  Fixed bug #28076.
  The sp_rcontext::create_case_expr_holder method has been
  modified to call Item_cache::get_cache in a new manner.
sql/sp_rcontext.h:
  Fixed bug #28076.
  The sp_rcontext::create_case_expr_holder method signature
  has been modified to pass Item pointers to the
  Item_cache::get_cache method.
sql/sql_class.cc:
  Fixed bug #28076.
  The select_max_min_finder_subselect::send_data method has been
  modified to call Item_cache::get_cache in a new manner.
mysql-test/t/subselect.test:
  Added test case for bug #28076.
mysql-test/r/subselect.result:
  Added test case for bug #28076.

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


mysql-test/r/group_by.result:
  Manual merge.
mysql-test/t/group_by.test:
  Manual merge.
sql/sql_select.cc:
  Manual merge.

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

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


sql/sql_select.cc:
  Auto merged

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


sql/sql_class.h:
  Auto merged
sql/sql_select.cc:
  manual merge

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.).


sql/sql_class.h:
  add documentation for some variables
sql/sql_select.cc:
  Don't forget const tables when counting read records!

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


mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged

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


mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged

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


mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged
sql-common/my_time.c:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged

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.


mysql-test/r/select.result:
  Show that we compare DATE/DATETIME-like strings as date(time)s
  now, rather than as bin-strings.
  Adjust older result as "2005-09-3a" is now correctly seen as
  "2005-09-3" + trailing garbage, rather than as "2005-09-30".
mysql-test/t/select.test:
  Show that we compare DATE/DATETIME-like strings as date(time)s
  now, rather than as bin-strings.
sql-common/my_time.c:
  correct/clarify date-related comments, particulary for check_date().
  doxygenize comment while at it.
sql/item_cmpfunc.cc:
  get_date_from_str() no longer signals an error when all we had
  was a warning-condition -- and one we already gave the user a
  warning for at that. Preamble doxygenized.

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

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

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


mysql-test/r/cast.result:
  Auto merged
mysql-test/t/cast.test:
  Auto merged
sql/item_timefunc.cc:
  Auto merged
sql/item_timefunc.h:
  Auto merged

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.


mysql-test/r/group_by.result:
  Added a test case for bug #32202.
mysql-test/t/group_by.test:
  Added a test case for bug #32202.
sql/sql_select.cc:
  In cases when groups in GROUP BY correspond to only one row and there
  is ORDER BY, rewrite the query to ORDER BY <group_by_columns> only if
  the columns in ORDER BY and GROUP BY are compatible, i.e. either one
  forms a prefix for another.