Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-19653

Add class Sql_cmd_create_table

Details

    Description

      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.

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17588 replicate-do filters cause errors when creating filtered-out tables on master with syntax unsupported on slave

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            bar Alexander Barkov created issue -
            bar Alexander Barkov made changes -
            Field Original Value New Value
            bar Alexander Barkov made changes -
            Rank Ranked higher
            bar Alexander Barkov made changes -
            Description
            To fix Mdev-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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}}.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            		To fix MDEV-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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}}.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            bar Alexander Barkov made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            bar Alexander Barkov made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            bar Alexander Barkov made changes -
            Description To fix MDEV-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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}}.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            		To fix MDEV-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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}}.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            bar Alexander Barkov made changes -
            Description To fix MDEV-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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}}.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            		To fix MDEV-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            bar Alexander Barkov made changes -
            Description To fix MDEV-17588, we need to postpone resolving of the storage engine to to 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 though 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and add the same member to Sql_cmd_alter_table.

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

            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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.
              }
            {code}

            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            		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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and adding the same member to Sql_cmd_alter_table.

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

            h3. Grammar changes to the `create_table_option` rule
            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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.
              }
            {code}

            h3. Grammar changes to the `storage_engine` rule
            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            bar Alexander Barkov made changes -
            Description 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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and adding the same member to Sql_cmd_alter_table.

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

            h3. Grammar changes to the `create_table_option` rule
            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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.
              }
            {code}

            h3. Grammar changes to the `storage_engine` rule
            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            		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:
            {code:code}
              LEX_CSTRING m_storage_engine_name;
            {code}
            and adding the same member to Sql_cmd_alter_table.

            h1. Proposed changes
            h2. `mysql_execute_command()` changes
            The `{{case SQLCMD_CREATE_TABLE}}` part of `mysql_execute_command()` will go to `Sql_cmd_create_table::execute()`.

            h2. Grammar changes to the `create_table_option` rule
            This code in sql_yacc.yy:
            {code:cpp}
            create_table_option:
              ENGINE_SYM opt_equal storage_engines
              {
                Lex->create_info.db_type= $3;
                Lex->create_info.used_fields|= HA_CREATE_USED_ENGINE;
              }
            {code}

            will change to:

            {code:cpp}
            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.
              }
            {code}

            h2. Grammar changes to the `storage_engine` rule
            The code in the rule {{storage_engines:}} will go to a new method in THD:
            {code:cpp}
              bool resolve_storage_engine(handlerton **ha, const LEX_CSTRING &name,
                                          bool tmp_table);
            {code}
            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.
            bar Alexander Barkov made changes -
            Fix Version/s 10.1.41 [ 23406 ]
            Fix Version/s 10.1 [ 16100 ]
            bar Alexander Barkov made changes -
            Fix Version/s 10.2.25 [ 23408 ]
            bar Alexander Barkov made changes -
            Fix Version/s 10.3.16 [ 23410 ]
            bar Alexander Barkov made changes -
            Fix Version/s 10.5.0 [ 23709 ]
            Fix Version/s 10.4.6 [ 23412 ]
            bar Alexander Barkov made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 97214 ] MariaDB v4 [ 133979 ]
            mariadb-jira-automation Jira Automation (IT) made changes -
            Zendesk Related Tickets 171096

            People

              bar Alexander Barkov
              bar Alexander Barkov
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.