MDEV-6099 Bad results for DATE_ADD(.., INTERVAL 2000000000000000000.0 SECOND)
MDEV-6097 Inconsistent results for CAST(int,decimal,double AS DATETIME)
MDEV-6100 No warning on CAST(9000000 AS TIME)

mysql_derived_merge() made correctly working with views.

It is triple bug with one test suite:
1. Incorrect outer table detection
2. Incorrect leaf table processing for multi-update (should be full like for usual updates and inserts)
3. ON condition fix_fields() fould be called for all tables of the query.

MariaDB-specific result replacement

A typo in include file caused the timeout counter to be 10x less than
expected. It was fixed in 5.5.20+ along with a bigger change, now also
fixing in 5.1-5.3.

MDEV-6134 SUBSTRING_INDEX returns wrong result for 8bit character sets when delimiter is not found

Recording the forgotten test results.

Both bugs are caused by the same problem: the function optimize_cond() should
update the value of *cond_equal rather than the value of join->cond_equal,
because it is called not only for the WHERE condition, but for the HAVING
condition as well.

Add test case.

Revert the old patch revid:monty@askmonty.org-20100325133339-7mkel6valai0b4lb

This patch caused the InnoDB part of the transaction to not be marked
read-write in some cases, which messes up XA commit (and likely other
stuff as well).

MDEV-5783 Assertion `0' failed in make_sortkey(SORTPARAM*, uchar*, uchar*) on ORDER BY HEX( UNCOMPRESSED_LENGTH( pk ) )

MDEV-5446: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' fails on EXPLAIN EXTENDED with VALUES function

field_index should be set correctly for null field created by Item_insert_value::fix_fields().

(as it's done in 10.0)

- With big_tables=ON, materialized table will use Aria (or MyISAM) SE, which
  allows prefix key reads. However, the temp.table has rec_per_key=NULL which
  causes the optimizer to crash when attempting to read index statistics for a 
  prefix index read.
- Fixed by providing a rec_per_key array with zeros (i.e. "no statistics data")

Item_default_value::arg can be NULL so walk() should take it into consideration.

Item_default_value::arg can be NULL so walk() should take it into consideration.

MDEV-5740: Assertion `!derived->first_select()->exclude_from_table_unique_test || derived->outer_select()-> exclude_from_table_unique_test' failed on 2nd execution of PS with derived_merge

Do not check tables of executed units.
Debug info about stages of derived tables execution added.

The calls of the function remove_eq_conds() may change the and/or structure
of the where conditions. So JOIN::equal_cond should be updated for non-recursive
calls of remove_eq_conds(). 

update_used_tables for the the where condition to update cached
indicators of constant subexpressions. It should be done before further
possible simplification of the where condition.

This change caused simplification of the executed where conditions 
in many test cases.

MDEV-4556 Server crashes in SEL_ARG::rb_insert with index_merge+index_merge_sort_union, FORCE INDEX
- merge_same_index_scans() may put the same SEL_ARG tree in multiple result plans.
  make it call incr_refs() on the SEL_ARG trees that it does key_or() on, because 
  key_or(sel_arg_tree_1, sel_arg_tree_2) call may invalidate SEL_ARG trees pointed 
  by sel_arg_tree_1 and sel_arg_tree_2.
    

In function ‘void* memset(void*, int, size_t)’,
    inlined from ‘void Lifo_buffer::set_buffer_space(uchar*, uchar*)’ at sql_lifo_buffer.h:70:5,
    inlined from ‘int DsMrr_impl::dsmrr_init(handler*, RANGE_SEQ_IF*, void*, uint, uint, HANDLER_BUFFER*)’ at multi_range_read.cc:895:62:
/usr/include/i386-linux-gnu/bits/string3.h:82:32: error: call to ‘__warn_memset_zero_len’ declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror]

It was intentional that the buffer is set to zero length there.

(gdb) p dbug_print_table_row(table)
  $33 = "SUBQUERY2_t1(col_int_key,col_varchar_nokey)=(7,c)"

- Item_direct_view_ref didn't clear its pointer to item_equal in ::cleanup.
- Some Item_direct_view_ref objects have statement lifetime (i.e. they
  survive across multiple EXECUTE commands). Item_equal objects live only for
  the duration of one EXECUTE. This caused Item_direct_view_ref to have a stale pointer,
  which could cause all sorts of effects. (In this bug's testcase it was pointing to
  the wrong Item_equal, causing wrong query result)
- Fixed by doing what Item_field::cleanup() does - don't keep item_equal pointer value.
- There is no testcase because the only testcase I've got is highly fragile (e.g. the
  bug will not show up if @@datadir is of the wrong length).