sometimes `mysqldump --hex-blob' overruned output buffer by '\0' byte.

The dump_table() function has been fixed to reserve 1 byte more for the
last '\0' byte of dumped string.


client/mysqldump.c:
  Fixed bug #28522.
  The dump_table() function has been fixed to reserve 1 byte more for the
  last '\0' byte of dumped string.
mysql-test/t/mysqldump.test:
  Updated test case for bug #28522.
mysql-test/r/mysqldump.result:
  Updated test case for bug #28522.

into  moonbone.local:/mnt/gentoo64/work/27563-bug-5.0-opt-mysql


sql/item_func.cc:
  Auto merged
sql/sp_head.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged

If a stored function or a trigger was killed it had aborted but no error
was thrown. This allows the caller statement to continue without a notice.
This may lead to a wrong data being inserted/updated to/deleted as in such
cases the correct result of a stored function isn't guaranteed. In the case
of triggers it allows the caller statement to ignore kill signal and to
waste time because of re-evaluation of triggers that always will fail
because thd->killed flag is still on.

Now the Item_func_sp::execute() and the sp_head::execute_trigger() functions
check whether a function or a trigger were killed during execution and
throws an appropriate error if so.
Now the fill_record() function stops filling record if an error was reported
through thd->net.report_error.


sql/item_func.cc:
  Bug#27563: Stored functions and triggers wasn't throwing an error when killed.
  Now the Item_func_sp::execute() function checks whether a trigger was killed
  during execution and throws an appropriate error if so.
sql/sp_head.cc:
  Bug#27563: Stored functions and triggers wasn't throwing an error when killed.
  Now the sp_head::execute_trigger() function checks whether a function was
  killed during execution and throws an appropriate error if so.
sql/sql_base.cc:
  Bug#27563: Stored functions and triggers wasn't throwing an error when killed.
  Now the fill_record() function stops filling record if an error was reported
  through thd->net.report_error.
mysql-test/r/kill.result:
  Added a test case for the bug#27563: Stored functions and triggers wasn't
  throwing an error when killed.
mysql-test/t/kill.test:
  Added a test case for the bug#27563: Stored functions and triggers wasn't
  throwing an error when killed.

into  dl145s.mysql.com:/users/mhansson/mysql/autopush/mysql-5.0o-pushee


sql/sql_select.cc:
  Auto merged

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


sql/sql_base.cc:
  Auto merged
sql/table.h:
  Auto merged

When processing the USE/FORCE index hints
the optimizer was not checking if the indexes 
specified are enabled (see ALTER TABLE).
Fixed by:
 Backporting the fix for bug 20604 to 5.0


mysql-test/r/key.result:
  Test for BUG 20604.
  The important part of the test is the explain output that 
  tests what indexes are used.
mysql-test/r/myisam.result:
  Bug #28476: test cases
mysql-test/t/key.test:
  Bug 20604: 
  The minimal test case that reveals the bug. The optimizer for 
  aggregates relies on keys disabled with ALTER TABLE ... DISABLE KEYS
  not being in the set TABLE::keys_in_use_for_query.
  When the execution engine tries to use a disabled index, MyISAM
  returns an error.
mysql-test/t/myisam.test:
  Bug #28476: test cases
sql/sql_base.cc:
  Bug #28476: 
   - Ignore disabled indexes in USE/FORCE index
sql/sql_select.cc:
  Bug 20604 : The intersection operation between table->s->keys_in_use 
  and table->keys_in_use_for_query is no longer necessary.
  We can trust that the latter is a subset of the former.
sql/table.h:
  Bug 20604:
  Added comments to TABLE_SHARE::keys_in_use and
  TABLE::keys_in_use_for_query.

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.0o-pushee


sql/item_sum.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
mysql-test/r/func_gconcat.result:
  Bug#23856: Manually merged
mysql-test/t/func_gconcat.test:
  Bug#23856: Manually merged

mode.

When a new DATE/DATETIME field without default value is being added by the
ALTER TABLE the '0000-00-00' value is used as the default one. But it wasn't
checked whether such value was allowed by the set sql mode. Due to this
'0000-00-00' values was allowed for DATE/DATETIME fields even in the
NO_ZERO_DATE mode.

Now the mysql_alter_table() function checks whether the '0000-00-00' value
is allowed for DATE/DATETIME fields by the set sql mode.
The new error_if_not_empty flag is used in the mysql_alter_table() function
to indicate that it should abort if the table being altered isn't empty.
The new new_datetime_field field is used in the mysql_alter_table() function
for error throwing purposes. 
The new error_if_not_empty parameter is added to the copy_data_between_tables()
function to indicate the it should return error if the source table isn't empty.


mysql-test/t/alter_table.test:
  Added a test case for the bug#27507: Wrong DATETIME value was allowed by
  ALTER TABLE in the NO_ZERO_DATE mode.
mysql-test/r/alter_table.result:
  Added a test case for the bug#27507: Wrong DATETIME value was allowed by
  ALTER TABLE in the NO_ZERO_DATE mode.
sql/sql_table.cc:
  Bug#27507: Wrong DATETIME value was allowed by ALTER TABLE in the NO_ZERO_DATE
  mode.
  Now the mysql_alter_table() function checks whether the '0000-00-00' value
  is allowed for DATE/DATETIME fields by the set sql mode.
  The new error_if_not_empty flag is used in the mysql_alter_table() function
  to indicate that it should abort if the table being altered isn't empty.
  The new new_datetime_field field is used in the mysql_alter_table() function
  for error throwing purposes. 
  The new error_if_not_empty parameter is added to the copy_data_between_tables()
  function to indicate the it should return error if the source table isn't empty.

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

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


mysql-test/r/type_newdecimal.result:
  merging
mysql-test/t/type_newdecimal.test:
  merging

decimal_round failed to perform a correct rounding 
of a decimal number if its first nine digits were '9'.
It just sets those digits to 0.


mysql-test/r/type_newdecimal.result:
  Bug #27984 Long Decimal Maths produces truncated results.
  test result
mysql-test/t/type_newdecimal.test:
  Bug #27984 Long Decimal Maths produces truncated results.
  test case
strings/decimal.c:
  Bug #27984 Long Decimal Maths produces truncated results.
  when to == from we break the data if we do to->buf[0]=0
  So now doing this after the data is moved and only
  if we really need to set to->buf[0] to zero

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

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

result max length changed for the 'decimal' fields
so test results have to be fixed


mysql-test/r/ps_2myisam.result:
  Bug #28361 Buffer overflow in DECIMAL code on Windows 
  test result fixed
mysql-test/r/ps_3innodb.result:
  Bug #28361 Buffer overflow in DECIMAL code on Windows 
  test result fixed
mysql-test/r/ps_4heap.result:
  Bug #28361 Buffer overflow in DECIMAL code on Windows 
  test result fixed
mysql-test/r/ps_5merge.result:
  Bug #28361 Buffer overflow in DECIMAL code on Windows 
  test result fixed
mysql-test/r/ps_7ndb.result:
  Bug #28361 Buffer overflow in DECIMAL code on Windows 
  test result fixed

into  magare.gmz:/home/kgeorge/mysql/work/B22855-5.0-opt


sql/item_subselect.cc:
  Auto merged
mysql-test/r/subselect3.result:
  manual merge
mysql-test/t/subselect3.test:
  manual merge

my_decimal in some cases can contain more decimal digits than
is officially supported (DECIMAL_MAX_PRECISION), so we need to
prepare bigger buffer for the resulting string.


mysql-test/r/type_newdecimal.result:
  bug #28361 Buffer overflow in DECIMAL code on Windows
  test result
mysql-test/t/type_newdecimal.test:
  bug #28361 Buffer overflow in DECIMAL code on Windows
  test case
  This test case doesn't fall in most cases even without the fix
  Still valgrind shows the problemn
sql/my_decimal.h:
  bug #28361 Buffer overflow in DECIMAL code on Windows
  DECIMAL_MAX_POSSIBLE_PRECISION introduced to be used in places,
  when we need to check for the number of digits technicaly possible
  in my_decimal.
  DECIMAL_MAX_STR_LENGTH fixed as it has to fit for the MAX_POSSIBLE_PRECISION

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt


mysql-test/r/ps.result:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/item.cc:
  Auto merged

into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0


mysql-test/r/ps.result:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/item.cc:
  Auto merged

mysql-test/r/sp_trans.result:
  added cleanup
mysql-test/r/strict.result:
  added cleanup
mysql-test/t/sp_trans.test:
  added cleanup
mysql-test/t/strict.test:
  added cleanup

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt


mysql-test/r/ps.result:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/item.cc:
  Auto merged

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

into  moonbone.local:/mnt/gentoo64/work/28261-bug-5.0-opt-mysql

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337

is involved.

The Arg_comparator::compare_datetime() comparator caches its arguments if
they are constants i.e. const_item() returns true. The
Item_func_get_user_var::const_item() returns true or false based on
the current query_id and the query_id where the variable was created.
Thus even if a query can change its value its const_item() still will return
true. All this leads to a wrong comparison result when an object of the
Item_func_get_user_var class is involved.

Now the Arg_comparator::can_compare_as_dates() and the
get_datetime_value() functions never cache result of the GET_USER_VAR()
function (the Item_func_get_user_var class).


mysql-test/t/type_datetime.test:
  A test case is added for the bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
  is involved.
mysql-test/r/type_datetime.result:
  A test case is added for the bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
  is involved.
sql/item_cmpfunc.cc:
  Bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
  is involved.
  Now the Arg_comparator::can_compare_as_dates() and the
  get_datetime_value() functions never cache result of the GET_USER_VAR()
  function (the Item_func_get_user_var class).

Conversion errors when constructing the condition for an
IN predicates were treated as if the affected column contains
NULL. If such a IN predicate is inside NOT we get wrong 
results.
Corrected the handling of conversion errors in an IN predicate 
that is resolved by unique_subquery (through 
subselect_uniquesubquery_engine).


mysql-test/r/subselect3.result:
  Bug#22855: test case
mysql-test/t/subselect3.test:
  Bug#22855: test case
sql/item_subselect.cc:
  Bug#22855: corrected the handling of conversion errors and
  NULL key values in IN predicate that is resolved by index
  lookup.

subqueries in WHERE conditions.
This bug was introduced by the patch for bug 27321.


mysql-test/r/subselect.result:
  Added a test case for bug #28337.
mysql-test/t/subselect.test:
  Added a test case for bug #28337.
sql/item.cc:
  Fixed bug #28337: wrong results for grouping queries with correlated
  subqueries in WHERE conditions.
  This bug was introduced by the patch for bug 27321.
  
  Now in the Item_field::fix_outer_field function we create an Item_outer_ref
  object for an outer reference only if it is used in the SELECT list or
  in the HAVING clause of the subquery against which the reference is resolved.

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

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

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

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work