Version for 4.1. Committed for merge.
If the result table is one of the select tables in INSERT SELECT,
we must not disable the result tables indexes before selecting.
mysql_execute_command() detects the match for other reasons and
adds the flag OPTION_BUFFER_RESULT to the 'select_options'.
In this case the result is put into a temporary table first.
Hence, we can defer the preparation of the insert
table until the result is to be used.
Version for 4.0. Committed for merge.
If the result table is one of the select tables in INSERT SELECT,
we must not disable the result tables indexes before selecting.
mysql_execute_command() detects the match for other reasons and
adds the flag OPTION_BUFFER_RESULT to the 'select_options'.
In this case the result is put into a temporary table first.
Hence, we can defer the preparation of the insert
table until the result is to be used.
The problem was that when a QUICK_SELECT access method is chosen,
test_if_skip_sort_order() discovered that the index being used
by the quick select will not deliver tuples in sorted order.
In this case test_if_skip_sort_order() tried to change the index
used by the quick select, but it didn't properly set the other
members of the quick select, and especially the range flags of
the ranges in QUICK_SELECT::ranges.
The fix re-invokes the function SQL_SELECT::test_quick_select
to correctly create a valid QUICK_SELECT object.
Now thd->mem_root is a pointer to thd->main_mem_root and THR_MALLOC is a pointer to thd->mem_root.
This gives us the following benefits:
- Allow us to easily detect if arena has already been swapped before (this fixes a bug in setup_conds() where arena was swaped twice in some cases)
- Faster swaps of arenas (as we don't have to copy the whole MEM_ROOT)
- We don't anymore have to call my_pthread_setspecific_ptr(THR_MALLOC,...) to change where memory is alloced. Now it's enough to set thd->mem_root
Added cases for bugs #6307 and #6460.
sql_select.cc:
Fixed the problem of bug reports #6307 and #6460.
The reported wrong result sets were due to the fact that
the added call of the fix_fields method for the built
AND condition that joined WHERE and ON conditions
broke ON expression, as it removed extra AND levels
in the built condition.
It looks like that no attributes of the built condition
are needed, so we don't have to call fix_fields here.
Simple optimzations and cleanups
Removed compiler warnings and fixed portability issues
Added client functions 'mysql_embedded()' to allow client to check if we are using embedded server
Fixes for purify
(Bug #4315: GROUP_CONCAT with ORDER BY returns strange results for TEXT fields
Bug #5564: Strange behaviour with group_concat and distinct
Bug #5970: group_concat doesn't print warnings)
crashes server (prepared statements)": the bug was that all boolean
items always recovered its original arguments at statement cleanup
stage.
This collided with Item_subselect::select_transformer, which tries to
permanently change the item tree to use a transformed subselect instead of
original one.
So we had this call sequence for prepare:
mysql_stmt_prepare -> JOIN::prepare ->
Item_subselect::fix_fields -> the item tree gets transformed ->
Item_bool_rowready_func2::cleanup, item tree is recovered to original
state, while it shouldn't have been;
mysql_stmt_execute -> attempts to execute a broken tree -> crash.
Now instead of bluntly recovering all arguments of bool functions in
Item_bool_rowready_func2::cleanup, we recover only those
which were changed, and do it in one place.
There still would exist a possibility for a collision with subselect
tranformation, if permanent and temporary changes were performed at the
same stage.
But fortunately subselect transformation is always done first, so it
doesn't conflict with the optimization done by propogate_cond_constants.
Now we have:
mysql_stmt_prepare -> JOIN::prepare -> subselect transformation
permanently changes the tree -> cleanup doesn't recover anything,
because nothing was registered for recovery.
mysql_stmt_execute -> JOIN::prepare (the tree is already transformed,
so it doesn't change), JOIN::optimize ->
propogate_cond_constants -> temporary changes the item tree
with constants -> JOIN::execute -> cleanup ->
the changes done by propogate_cond_constants are recovered, as
they were registered for recovery.
identical to another in result"
According to SQL standard queries like
"select t1.a as col from t1, t2 order by a" should return an error if
both tables contain field a.
Added a test case for bug #5333.
null_key.result, key_primary.result:
Made covering index usable for const tables.
sql_select.cc:
Made covering index usable for const tables:
downported the corresponding code from 4.1.
Simultaneously fixed bug #5333 reported for 4.1.
The bug was due to the fact that field index in join
structures was always set to 0 for const tables.
Use 'mysqltest' as test database instead of test_$1 or test1,test2 to not accidently delete an important database
Safety fix for mailformed MERGE files
execute crashes server": we were deleting lex->result
after each execute, but prepared statements assumed that
it's left intact.
The fix adds cleanup() method to select_result hierarchy,
so that result objects can be reused.
Plus we now need to delete result objects more wisely.
