To fix MDEV-17588, we need to postpone resolving of the storage engine to the handlerton pointer, from `mysql_parse()` time to `mysql_execute_command()` time.

So we need to pass the storage engine name, scanned in the ENGINE=XXX clause, through LEX.

Adding the storage engine name as a member to LEX (directly, or through its parts like HA_CREATE_INFO) is not nice:

• LEX is already huge enough.
• The logic of LEX initialization and updating is already too complex.

The easiest way to solve this would be moving the create table related code to a new class Sql_cmd_create_table, with a member:

  LEX_CSTRING m_storage_engine_name;

and adding the same member to Sql_cmd_alter_table.

Proposed changes

`mysql_execute_command()` changes

The `case SQLCMD_CREATE_TABLE` part of `mysql_execute_command()` will go to `Sql_cmd_create_table::execute()`.

Grammar changes to the `create_table_option` rule

This code in sql_yacc.yy:

create_table_option:

  ENGINE_SYM opt_equal storage_engines

  {

    Lex->create_info.db_type= $3;

    Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;

  }

will change to:

create_table_option:

  ENGINE_SYM opt_equal ident_or_text

  {

    // Set m_storage_engine_name of the current Sql_cmd_create_table or Sql_cmd_alter_table.

  }

Grammar changes to the `storage_engine` rule

The code in the rule storage_engines: will go to a new method in THD:

  bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,

                              bool tmp_table);

so it can be reused by:

• The `storage_engines` rule
• Sql_cmd_create_table::execute()
• Sql_cmd_alter_table::execute()

This change should fix MDEV-17588 automatically.