Analysis:
Before calling:
  write_record= (select->skip_record(thd) > 0);
the function find_all_keys needs to restore the original read/write
sets of the table that is sorted if the condition select->cond
contains a subquery.

This didn't happen in this test case because the flag "with_subselect"
was not set properly for select->cond.

The reason for the flag not being set properly, was that this condition
was rewritten by add_cond_and_fix() inside make_join_select() by:

      /* Add conditions added by add_not_null_conds(). */
      if (tab->select_cond)
        add_cond_and_fix(thd, &tmp, tab->select_cond);

However, the function add_cond_and_fix() called the shortcut method
Item::quick_fix_field() that didn't update the "with_subselect"
property.

Solution:
Call the complete Item::fix_fields() to update all Item properties,
including "with_subselect".

Analysis:
The failed assert is a result of calling Item_sum_distinct::clear()
on an incomplete object for which Item_sum_distinct::setup() was
not yet called.

The reason is that JOIN::exec for the outer query calls JOIN::reinit()
for all its subqueries, which in turn calls clear() for all aggregate
functions of the subqueries. The call stack is:
mysql_explain_union -> mysql_select -> JOIN::exec -> select_desribe ->
mysql_explain_union -> mysql_select -> JOIN::reinit

This assert doesn't fail in the main 5.3 because constant subqueries
are being executed during the optimize phase of the outer query,
thus the Unique object is created before calling JOIN::exec for the
outer query, and Item_sum_distinct::clear() actually cleans the
Unique object.

Solution:
The best solution is the obvious one - substitute the assert with
a test whether Item_sum_distinct::tree is NULL.

Analysis:
The crash in EXPLAIN resulted from an attempt to print the
name of the internal temporary table created to compute
distinct for the innermost subquery of the test case.
Such tables do not have a corresponding TABLE_LIST (table
reference), hence the crash. The reason for this was that
the subquery was executed as part of constant condition
evaluation before EXPLAIN attempts to print the table name.
During the subquery execution, the subquery JOIN_TAB and
its table are substituted by a temporary table in
make_simple_join.

Solution:
Similar to the analogous case for other Items than the
IS NULL function, do not evaluate expensive constant
conditions.

Fixed LP BUG#714808 Assertion `outer_lookup_keys <= outer_record_count'

Analysis:

The function best_access_path() computes the number or records as
follows:

...
      if (rec < MATCHING_ROWS_IN_OTHER_TABLE)
        rec= MATCHING_ROWS_IN_OTHER_TABLE; // Fix for small tables
...
              if (table->quick_keys.is_set(key))
                records= (double) table->quick_rows[key];
              else
              {
                /* quick_range couldn't use key! */
                records= (double) s->records/rec;
              }

Above MATCHING_ROWS_IN_OTHER_TABLE == 10, and s->records == 1,
thus we get an estimated 0.1 records. As a result JOIN::get_partial_join_cost()
for the outer query computes outer_record_count == 0.1 records, which is
meaningless in this context.

Solution:
Round row count estimates that are < 1 to 1.

Fixed a memory leak found by valgrind. The memory leak was
a result of JOINs corresponding to subselects in a global
ORDER BY of a UNION not being cleaned up because the
fake_select of the UNION didn't point down to the subquery
select.

Adjusted test cases in accordance with the implementation.

- fixed incorrect query plans that resulted from emptying the
  keyuse array with the access methods of the non-modified query
  plan.
- fixed compiler warning.

sql/item.cc:
  Wrapper added.
sql/item.h:
  Wrapper added.
sql/mysql_priv.h:
  Wrap function added.
sql/sql_base.cc:
  Wrap function added.
  Fix of problem with WHERE consist of alone outer reference field by wrapping it.
sql/sql_select.cc:
  Fix of problem with HAVING consist of alone outer reference field by wrapping it.

Analysis:
The cause for the failing assert was that between preparation
and execution of a DELETE prepared statement, the server reverted
back all changes of the item tree. Since the substitution of
Item_in_subselect by an Item_in_optimizer was recorded via
change_item_tree, thus the rollback of the item tree affected
the substitution as well. As a result the execution of the PS
called Item_in_subselect::val_int(), which was never supposed
to be called.

Solution:
Replace change_item_tree with assignment. This is OK because
the Item objects used for substitution are created in PS memory.

Fixed query plans with loose index scan degraded into index scan.

Analysis:
With MWL#89 subqueries are no longer executed and substituted during
the optimization of the outer query. As a result subquery predicates
that were previously executed and substituted by a constant before
the range optimizer were present as regular subquery predicates during
range optimization. The procedure check_group_min_max_predicates()
had a naive test that ruled out all queries with subqueries in the
WHERE clause. This resulted in worse plans with MWL#89.

Solution:
The solution is to refine the test in check_group_min_max_predicates()
to check if each MIN/MAX argument is referred to by a subquery predicate.

Analysis:
Close to its end JOIN::optimize() assigns having to tmp_having, and
sets the having clause to NULL:

  tmp_having= having;
  if (select_options & SELECT_DESCRIBE)
  {
    error= 0;
    DBUG_RETURN(0);
  }
  having= 0;

At the same time, this query detects an empty result set, and calls
return_zero_rows(), which checks the HAVING clause as follows:

    if (having && having->val_int() == 0)
      send_row=0;

However having has been already set to NULL, so return_zero_rows
doesn't check the having clause, hence the wrong result.

Solution:
Check join->tmp_having in addition to join->having.

There is no additional test case, because the failure was in
the current regression test.

This fixes the wrong result in tests like compress, join, join_cache, greedy_optimizer and select_pkeycache

When stored in a key buffer any varchar field has a length prefix
that always takes 2 bytes.

Added a test case for bug #695442 - a duplicate of bug 694092.

The bug was the result of a bad merge maria-5.2-wl21 -> 5.3.

One of the hash functions employed by the BNLH join algorithm
calculates the the value of hash index for key value utilizing
every byte of the key buffer. To make this calculation valid
one has to ensure that for any key value unused bytes of the 
buffer are filled with with a certain filler. We choose 0 as
a filler for these bytes.

Added an optional boolean parameter with_zerofill to the function
key_copy. If the value of the parameter is TRUE all unused bytes
of the key buffer is filled with 0. 

In some cases the function make_cond_for_index() was mistaken
when detecting index only pushdown conditions for a table: 
a pushdown condition that was not index only could be marked
as such.
It happened because the procedure erroneously used the markers
for index only conditions that remained from the calls of
this function that extracted the index conditions for other 
tables.
Fixed by erasing index only markers as soon as they are need
anymore.

  
- Post-review fixes. Intermediate commit to address review point 1.6.
- Fixed valgrind warnings

Lifted the limitation that hash join could not be used over 
varchar fields with non-binary collation.

- Merge with 5.3-main

set thd->password appropriately also for cases when a user was not found.

- Fixes for the second fix: take into account case where we don't need to save/restore the scan.

Switch from "Disable identical key handling optimization when
  IndexConditionPushdown is used" approach
To 
 an approach where we save/restore index tuple and so can use index condition pushdown.

mwl#21.

It was missing from EXTRA_DIST in Makefile.am.