The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
- current_arena to stmt_arena: the thread may have more than one
'current' arenas: one for runtime data, and one for the parsed
tree of a statement. Only one of them is active at any moment.
- set_item_arena -> set_query_arena, because Item_arena was renamed to
Query_arena a while ago
- set_n_backup_item_arena -> set_n_backup_active_arena;
the active arena is the arena thd->mem_root and thd->free_list
are currently pointing at.
- restore_backup_item_arena -> restore_active_arena (with the same
rationale)
- change_arena_if_needed -> activate_stmt_arena_if_needed; this
method sets thd->stmt_arena active if it's not done yet.
multi-threaded environment".
To avoid deadlocks between several simultaneously run account management
commands (particularly between FLUSH PRIVILEGES/SET PASSWORD and GRANT
commands) we should always take table and internal locks during their
execution in the same order. In other words we should first open and lock
privilege tables and only then obtain acl_cache::lock/LOCK_grant locks.
Item_func_group_concat::fix_fields() set maybe_null flag to 0, and set it to
1 only if some of it's arguments may be null. When used in subquery in tmp
table created field which can't be null. When no data retireved result field
have to be set to null and error mentioned in bug report occurs. Also this
bug can occur if selecting from not null field in empty table.
Function group_concat now marked maybe_null from the very beginning not only
if some of it's argument may be null.
Fix bug #12410 : InnoDB was too permissive with LOCK TABLE ... READ LOCAL, and alowed new inserts to the table; we now make READ LOCAL equivalent to READ for InnoDB; note that this will cause slightly more locking in mysqldump, but makes the InnoDB table dumps consistent with MyISAM table dumps; note that the real code change patch was accidentally pushed with my another patch 5 minutes ago
Fix bug #12852 : do not increment the open handle count to a table if the table does not have an .ibd file and InnoDB decides to return an error from the ::open() function; then the table can be dropped even if the user has tried to open it
view.
For Item_func_strcmp print() was not defined and for this class was called
print_op of it's parent class. Because of this strcmp() was printed wrongly
and this results int creation of broken view.
Added function Item_func_strcmp::print() which correctly prints strcmp()
function.
