on duplicate key".
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in
stored routine or as prepared statement and which in its ON DUPLICATE
KEY clause erroneously tried to assign value to a column mentioned only
in its SELECT part was properly emitting error on the first execution
but succeeded on the second and following executions.
Code which is responsible for name resolution of fields mentioned in
UPDATE clause (e.g. see select_insert::prepare()) modifies table list
and Name_resolution_context used in this process. It uses
Name_resolution_context_state::save_state/restore_state() to revert
these modifications. Unfortunately those two methods failed to revert
properly modifications to TABLE_LIST::next_name_resolution_table
and this broke name resolution process for successive executions.
This patch fixes Name_resolution_context_state::save_state/restore_state()
in such way that it properly handles TABLE_LIST::next_name_resolution_table.
Blocked evaluation of constant objects of the classes
Item_func_is_null and Item_is_not_null_test at the
prepare phase in the cases when the objects used subqueries.
Removed an assertion that was not valid for the cases where the query
in a prepared statement contained a single-row non-correlated
subquery that was used as an argument of the IS NULL predicate.
Bug#4968 "Stored procedure crash if cursor opened on altered table"
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from
stored procedure."
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Test cases for bugs 4968, 19733, 6895 will be added in 5.0.
Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).
In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table were not
re-execution friendly: during their operation they used to modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc
for drop_it.remove() and similar patterns to find evidence.
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement.
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
The problem of crashing bug 22060 stemmed from the fact that the above
metnioned functions were not only modifying HA_CREATE_INFO structure in
LEX, but also were changing it to point to areas in volatile memory of
the execution memory root.
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO (note that code in 5.1 already creates and
uses a copy of this structure in mysql_create_table()/alter_table(),
but this approach didn't work well for CREATE TABLE SELECT statement).
prepared statement and subquery.
When a field of a view from an outer select is resolved the find_field_in_view
function creates an Item_direct_view_ref object that references the
corresponding view underlying field. After that the view_ref is marked
as a dependent one. While resolving view underlying field it also get
marked as a dependent one due to current_select still points to the subselect.
Marking the view underlying field is wrong and lead to attaching conditions
to a wrong table and thus to the wrong result of the whole statement.
Now mark_select_range_as_dependent() function isn't called for fields from a
view underlying table.
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
or CREATE TRIGGER statements with a syntax error in it, the preparation
would fail with syntax error message, but the memory could be corrupted.
The problem occurred because we switch memroot when parse stored
routine or trigger definitions, and on parse error we restored the
original memroot only after performing some memory operations. In more
detail:
- prepared statement would activate its own memory root to parse
the definition of the stored procedure.
- SP would reset this memory root with its own memory root to
parse SP statements
- a syntax error would happen
- prepared statement would restore the original memory root
- stored procedure would restore what it thinks was the original
memory root, but actually was the statement memory root.
That led to double free - in destruction of the statement and in
a next call to mysql_parse().
The solution is to restore memroot right after the failed parsing.
Do not consider SHOW commands slow queries, just because they don't use proper indexes.
This bug fix is not needed in 5.1, and the code changes will be null merged. However, the test cases will be propogated up to 5.1.
statement.
The problem was that during statement re-execution if the result was
empty the old result could be returned for group functions.
The solution is to implement proper cleanup() method in group
functions.
Re-execution of a parametrized prepared statement or a stored routine
with a SELECT that use LEFT JOIN with second table having only one row
could yield incorrect result.
The problem appeared only for left joins with second table having only
one row (aka const table) and equation conditions in ON or WHERE clauses
that depend on the argument passed. Once the condition was false for
second const table, a NULL row was created for it, and any field involved
got NULL-value flag, which then was never reset.
The cause of the problem was that Item_field::null_value could be set
without being reset for re-execution. The solution is to reset
Item_field::null_value in Item_field::cleanup().
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.
