- "Using MRR" is no longer shown with range access.
- Instead, both range and BKA accesses will show one of the following:
  = "Rowid-ordered scan"
  = "Key-ordered scan"
  = "Key-ordered Rowid-ordered scan"
depending on whether DS-MRR implementation will do scan keys in order, rowids in order,
or both.
- The patch also introduces a way for other storage engines/MRR implementations to
  pass information to EXPLAIN output about the properties of employed MRR scans.

Analysis:
There are two code paths through which JOIN::exec may produce
an all-NULL row for an empty result set. One goes via the
function return_zero_rows(), when query processing detectes
early that the where clause is false, the other one is via
do_select() in the case of join execution.

In the case of do_select(), the problem was that the executioner
didn't set TABLE::null_row to 1. As result when sending the only
result row, the evaluation of each field didn't detect that all
non-aggregated fields are NULL, because Field::is_null returned
true, after checking that field->table->null_row was false.

Given that the each non-aggregated field was not considered NULL,
select_result::send_data sent whatever was in the buffer of each
field. However, since there was no actual data in the field buffer,
send_data() accessed and sent whatever junk was in the field's
data buffer.

Solution:
Similar to the analogous case in return_zero_rows() mark all
tables that their current row is NULL before sending the
artificailly created NULL row.

Analysis:
A query with implicit grouping is one with aggregate functions and
no GROUP BY clause. MariaDB inherits from MySQL an SQL extenstion
that allows mixing aggregate functions with non-aggregate fields.
If a query with such mixed select clause produces an empty result
set, the meaning of aggregate functions is well defined - either
NULL (MIN, MAX, etc.), or 0 (count(*)). However the non-aggregated
fields must also have some value, and the only reasonable value in
the case of empty result is NULL.

The cause of the many wrong results was that if a field is declared
as non-nullable (e.g. because it is a PK or NOT NULL), the semantic
analysis and the optimization phases treat this field as non-nullable,
and generate all related query plan elements based on this assumption.

Later during execution, these incorrectly configured/generated query
plan elements result in a wrong result because the selected fields
are not null due to the not-null assumption during optimization.

Solution:
Detect before the context analysys phase that a query uses implicit
grouping with mixed aggregates/non-aggregates, and set all fields
as nullable. The parser already walks the SELECT clause, and
already sets Item::with_sum_func for Items that reference aggreagate
functions. The patch adds a symmetric Item::with_field so that all
Items that reference an Item_field are marked during their
construction at parse time in the same way as with aggregate function
use.

Analysis:
The reason for the crash was that the inner subquery was executed
via a scan on a final temporary table applied after all other
operations. This final operation is implemented by changing the
contents of the JOIN object of the subquery to represent a table
scan over the temp table. At the same time query optimization of
the outer subquery required evaluation of the inner subquery, which
happened before the actual EXPLAIN. The evaluation left the JOIN
object of the inner subquery in the changed state, where it represented
a table scan over a temp table, and EXPLAIN crashed because the temp
table is not associated with any table reference (TABLE_LIST object).
The reason the JOIN was not restored was because its saving/restoration
was controlled by the join->select_lex->uncacheable flag, which was
not set in the case of materialization.

Solution:
In the methods Item_in_subselect::[single | row]_value_transformer() set:
    select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
In addition, for symmetry, change:
    master_unit->uncacheable|= UNCACHEABLE_EXPLAIN;
instead of UNCACHEABLE_DEPENDENT because if a subquery was not
dependent initially, the changed methods do not change this
fact. The subquery may later become correlated if it is transformed
to an EXISTS query, but it may stay uncorrelated if executed via
materialization.

- Make get_constant_key_infix() take into account that there may be SEL_TREEs with
  type=SEL_ARG::MAYBE_KEY, which it cannot process, because they are not real ranges
  but rather indications that we might have been able to construct a range if we had
  values for some other tables' fields. 
  (check_quick_select() already has such check)

- Assume that outside subquery references are known when doing "Range-checked-for-each-record" check.

Backport testcase: BUG#45863 "Assertion failed: (fixed == 0), function fix_fields(), file item.cc, line 4448"
(The fix was backported with subquery code backport)

tmptable needed

The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.

Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.

file .\item_subselect.cc, line 836
     
IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.
      
Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Back-ported to 5.0s

about the employed join algorithms.
Refactored constructors of the JOIN_CACHE* classes.

      
The EXISTS transformation has additional switches to catch the known corner
cases that appear when transforming an IN predicate into EXISTS. Guarded
conditions are used which are deactivated when a NULL value is seen in the
outer expression's row. When the inner query block supplies NULL values,
however, they are filtered out because no distinction is made between the
guarded conditions; guarded NOT x IS NULL conditions in the HAVING clause that
filter out NULL values cannot be de-activated in isolation from those that
match values or from the outer expression or NULL's.

The above problem is handled by making the guarded conditions remember whether
they have rejected a NULL value or not, and index access methods are taking
this into account as well. 

The bug consisted of 

1) Not resetting the property for every nested loop iteration on the inner
   query's result.

2) Not propagating the NULL result properly from inner query to IN optimizer.

3) A hack that may or may not have been needed at some point. According to a
   comment it was aimed to fix #2 by returning NULL when FALSE was actually
   the result. This caused failures when #2 was properly fixed. The hack is
   now removed.

The fix resolves all three points.

Cache parameters print added in EXPLAIN EXTENDED output.

mysql-test/r/compare.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/group_by.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect3.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect3_jcl6.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect4.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect_cache.result:
  Added test suite for LP BUG#615760
mysql-test/r/subselect_mat.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect_no_mat.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect_no_opts.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect_no_semijoin.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect_sj.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/r/subselect_sj_jcl6.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/suite/pbxt/r/subselect.result:
  Cache parameters print added in EXPLAIN EXTENDED output.
mysql-test/t/subselect_cache.test:
  Cache parameters print added in EXPLAIN EXTENDED output.
sql/item.cc:
  Item::set_expr_cache result fixed according to its description.
  
  Cache parameters print added in EXPLAIN EXTENDED output.
sql/item.h:
  Cache parameters print added in EXPLAIN EXTENDED output.
sql/item_cmpfunc.cc:
  Check on double cache assignment added into the transformation methods.
sql/item_cmpfunc.h:
  Check on double cache assignment added into the transformation methods.
sql/item_subselect.cc:
  Check on double cache assignment added into the transformation methods.
sql/item_subselect.h:
  Check on double cache assignment added into the transformation methods.
sql/sql_expression_cache.cc:
  Cache parameters print added.
sql/sql_expression_cache.h:
  Cache parameters print added.
sql/sql_select.cc:
  Removed unused method (now it is impossible to make double transformation with the cache).
sql/sql_select.h:
  Removed unused method.

mysql-test/r/compare.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/explain.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/group_by.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect3.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect3_jcl6.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect4.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect_mat.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect_no_mat.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect_no_opts.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect_no_semijoin.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect_sj.result:
  Expression cache added to EXPLAIN EXTENDED output.
mysql-test/r/subselect_sj_jcl6.result:
  Expression cache added to EXPLAIN EXTENDED output.
sql/item.h:
  Expression cache added to EXPLAIN EXTENDED output.

Fix for LP#612894 Some aggregate functions (such as MIN MAX) work incorrectly in subqueries after getting NULL value


mysql-test/r/group_by.result:
  Added test that showed problems that no_rows_in_results() didn't work for expressions
mysql-test/r/subselect4.result:
  Test case for LP#612894
mysql-test/t/group_by.test:
  Added test that showed problems that no_rows_in_results() didn't work for expressions
mysql-test/t/subselect4.test:
  Test case for LP#612894
sql/item.h:
  Added restore_to_before_no_rows_in_result()
  Added function processor for no_rows_in_results() and restore_to_before_no_rows_in_results() to ensure it works with functions
  Fix that above functions are handled by Item_ref()
sql/item_func.h:
  Ensure that no_rows_in_results() and restore_to_before_no_rows_in_result() are called for all function arguments
sql/item_sum.cc:
  Added restore_to_before_no_rows_in_result() to restore settings after Item_sum_hybrid::no_rows_in_result() was called.
  This is needed to handle the case where we have made 'make_const()' on the item in opt_sum(), but the item will be reused again in a sub query.
  Ignore multiple calls to no_rows_in_result() as Item_ref is calling it twice.
sql/item_sum.h:
  Added restore_to_before_no_rows_in_result();
sql/sql_select.cc:
  Added reset of no_rows_in_result() for JOIN::reinit()
sql/sql_select.h:
  Added marker if no_rows_in_result() is called.

file .\item_subselect.cc, line 836

IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.

Fixed by not pre-evaluating LIKE arguments in view prepare mode.

- Unify EXPLAIN printout for <subqueryN> tables with regular tables
- Update test results for <subqueryN> tables:
  s/unique_key/distinct_key/g
  s/1.0/100.0/ for "filtered" column

MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE
- Change "SUBQUERY#n" to "<subquery{n}>" in EXPLAIN output. We need to it to be
  lowercase so that EXPLAIN results do not differ in case between systems with
  case-sensitive and case-insensitive filesystems.
- Remove garbage comments, add better comments.

- for Item-based materialization, it was "materialized subselect"
- for SJ-Materialization it was "subquery%d"

- Add Item_in_subselect::get_identifier() that returns subquery's id
- Change select_describe() to produce output in new format
- Update test results (checked)

- Update test results
- More comments
- Add Item_in_optimizer::transform() which was lost in backport

There are still test failures because of:
- Wrong query results in outer join + semi join
- EXPLAIN output differences

 query
      
The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT 
and substituted it for a check on the presence of 
Item_ident::depended_from.
Removing it altogether was wrong : OUTER_REF_TABLE_BIT should 
still be checked in addition to depended_from (because it's not 
set in all cases and doesn't contradict to the check of depended_from).
Fixed by returning the old condition back as a compliment to the 
new one.

  function,file sql_base.cc

When uncacheable queries are written to a temp table the optimizer must 
preserve the original JOIN structure, because it is re-using the JOIN 
structure to read from the resulting temporary table.
This was done only for uncacheable sub-queries. 
But top level queries can also benefit from this mechanism, specially if 
they're using index access and need a reset.
Fixed by not limiting the saving of JOIN structure to subqueries
exclusively.
Added a new test file to extend the existing (large) subquery.test.