create_tmp_table()".
The fix for bug 21787 "COUNT(*) + ORDER BY + LIMIT returns wrong
result" introduced valgrind warnings which occured during execution
of information_schema.test and sp-prelocking.test in version 5.0.
There were no user visible effects.
The latter fix made create_tmp_table() dependant on
THD::lex::current_select value. Valgrind warnings occured when this
function was executed and THD::lex::current_select member pointed
to uninitialized SELECT_LEX instance.
This fix tries to remove this dependancy by moving some logic
outside of create_tmp_table() function.
post-review fixes as indicated by Serg.
manual testing of error cases done in 5.0 due to support for DBUG_EXECUTE_IF
to insert errors.
Unable to write test case for mysql-test until 5.1 due to support for setting
debug options at runtime.
statement that uses an aggregating IN subquery with
HAVING clause.
A wrong order of the call of split_sum_func2 for the HAVING
clause of the subquery and the transformation for the
subquery resulted in the creation of a andor structure
that could not be restored at an execution of the prepared
statement.
containing a select statement that uses an aggregating IN subquery.
Added a parameter to the function fix_prepare_information
to restore correctly the having clause for the second execution.
Saved andor structure of the having conditions at the proper moment
before any calls of split_sum_func2 that could modify the having structure
adding new Item_ref objects. (These additions, are produced not with
the statement mem_root, but rather with the execution mem_root.)
In practice this means that handlerton is now created by the server and is passed to the engine. Plugin startups can now also control how plugins are inited (and can optionally pass values). Bit more flexibility to those who want to write plugin interfaces to the database.
equal constant under any circumstances.
In fact this substitution can be allowed if the field is
not of a type string or if the field reference serves as
an argument of a comparison predicate.
if join is used
For procedures with selects that use complicated joins with ON expression
re-execution could erroneously ignore this ON expression, giving
incorrect result.
The problem was that optimized ON expression wasn't saved for
re-execution. The solution is to properly save it.
Select_type in the EXPLAIN output for the query SELECT * FROM t1 was
'SIMPLE', while for the query SELECT * FROM v1, where the view v1
was defined as SELECT * FROM t1, the EXPLAIN output contained 'PRIMARY'
for the select_type column.
The problem was due to a prior fix for BUG 9676, which limited
the rows stored in a temporary table to the LIMIT clause. This
optimization is not applicable to non-group queries with aggregate
functions. The fix disables the optimization in this case.
account by the optimizer.
Now all row equalities are converted into conjunctions of
equalities between row elements. They are taken into account
by the optimizer together with the original regular equality
predicates.
const tables. This resulted in choosing extremely inefficient
execution plans in same cases when distribution of data in
joined were skewed (see the customer test case for the bug).
