TODO: handle_query is deleted

[andyli029]

No description provided.

[RingsC]

commit 59504c14c2cc5d2472d043c2487460db5b82a547
Author: Roy Lyseng [email protected]
Date: Sat Nov 21 18:02:45 2020 +0100

Bug#32079103: Assertion failure: trx->lock.table_locks.empty()

The symptom for this problem is that we may have an inconsistent
InnoDB transaction after creating a non-InnoDB table from a
query expression that operates on InnoDB tables.
The cause of this is the refactoring that moved creating the
new table into Query_result_create::start_execution().
Before that, the new table was created in
Query_result_create::prepare(), however with single preparation,
it could not be created as part of query preparation.

The problem with the new strategy was that table creation would
occur after locking the tables of the query expression, and thus
the implicit commit of the table creation would clear the locks.
As a result, evaluating the query expression would access unlocked
InnoDB tables, leading to an inconsistent InnoDB state.
When the session was immediately terminated, the InnoDB transaction
state checker would report a problem.

The solution to the problem is to remove the table creation from
Query_result_create::start_execution() and place it in a new function
Query_result_create::create_table_for_select(). We also implement a
**simplified version of handle_query() called populate_table()**, since
the former is not really designed for DDL statements that perform
intermediate commits.

**handle_query() itself is removed because it is no longer in use.**

Reviewed by: Gopal Shankar <[email protected]>
Reviewed by: Chaithra Gopalareddy <[email protected]>

[RingsC]

simplified version of handle_query() called populate_table()
and handle_query() itself is removed because it is no longer in use. @andyli029 @DandreChen @lujiashun