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

Allow SP variables as LOAD DATA out parameters

Details

    • Task
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • Stored routines
    • None

    Description

      We currently allow user variables and SP variables as out parameters in:

      • FETCH INTO @uservar vs FETCH INTO spvar
      • CALL p1(@uservar_as_out_param) vs CALL p1(spvar_as_out_param)

      But LOAD DATA is an exception:

      It's possible to do:

      LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;

      But its not possible to do inside a stored routine:

      LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;

      It can be useful for stricter data type control in the SET clause.

      Under terms of this task we'll do the following:

      • Derive Item_splocal, Item_splocal_row_field, Item_user_var_as_out_param, and possibly Item_trigger_field from Load_data_outvar (added in MDEV-15597).
      • Possibly get rid of Item_user_var_as_out_param and replace it to Item_func_get_user_var or Item_func_get_user_var. This change is optional, we'll decide during development.
      • Possibly change collecting LOAD DATA targets from List<Item> to List<Load_data_outvar>. So in case if we don't remove Item_user_var_as_out_param, we can at least remove its inheritance from Item and its useless methods like val_str, which currently do DBUG_ASSERT.

      Attachments

        Issue Links

          is blocked by

          Task - A task that needs to be done. MDEV-15597 Add class Load_data_outvar and avoid using Item::STRING_ITEM for Item_user_var_as_out_param detection

          • Major - Major loss of function.
          • 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 -
            Priority Major [ 3 ] Minor [ 4 ]
            bar Alexander Barkov made changes -
            Description Allow SP variables as LOAD DATA out parameters

            We allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CAL p1(spvar_as_out_param}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CAL p1(spvar_as_out_param}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CAL p1(spvar_as_out_param}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_out_param
            {
            public:
              Load_data_out_param() { }
              virtual ~Load_data_out_param() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_out_param}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_out_param>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_outvar
            {
            public:
              Load_data_outvar() { }
              virtual ~Load_data_outvar() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Introduce a new class:
            {code:cpp}
            class Load_data_outvar
            {
            public:
              Load_data_outvar() { }
              virtual ~Load_data_outvar() { }
              virtual void load_data_set_null_value(CHARSET_INFO *cs) = 0;
              virtual void load_data_set_value(const char *str, uint length,
                                               CHARSET_INFO *cs) = 0;
              virtual void load_data_print(THD *thd, String *str) = 0;
            };
            {code}
            - Derive {{Item_field}}, {{Item_ref}}, {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}}.
            - Move similar pieces of the code in {{sql_load.cc}} into virtual implementations of these {{Item_xxx}}.

            Code blocks like this (they repeat around six times):
            {code:cpp}
                  Item *real_item= item->real_item();

                  if (item->type() == Item::STRING_ITEM)
                  {
                    ((Item_user_var_as_out_param *)item)->set_value((char*) pos, length,
                                                                    read_info.read_charset);
                  }
                  else if (!real_item)
                  {
                    my_error(ER_NONUPDATEABLE_COLUMN, MYF(0), item->name);
                    DBUG_RETURN(1);
                  }
                  else
                  {
                    ...
                    field->store((char *) tag->value.ptr(), tag->value.length(), cs);
                    ...
                  }
            {code}
            will be simplified to one line:
            {code:cpp}
              item->load_data_set_value(...)
            {code}

            - The above change will also remove dangerous tests for {{Item::STRING_ITEM}} and dangerous casts to {{Item_user_var_as_out_param}}. So this will remove potential bugs like MDEV-12696, when the code works fine for {{LOAD DATA}} but crashes/fails for {{LOAD XML}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.


            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.
            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}}.

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.
            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}} (added in MDEV-15597).

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.
            bar Alexander Barkov made changes -
            Description We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}} (added in MDEV-15597).

            - We'll also possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - We'll also possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.
            		We currently allow user variables and SP variables as out parameters in:

            - {{FETCH INTO @uservar}} vs {{FETCH INTO spvar}}
            - {{CALL p1(@uservar_as_out_param)}} vs {{CALL p1(spvar_as_out_param)}}


            But {{LOAD DATA}} is an exception:

            It's possible to do:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
            {code}

            But its not possible to do inside a stored routine:
            {code:sql}
            LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, spvar1) SET column2 = spvar1/100;
            {code}
            It can be useful for stricter data type control in the {{SET}} clause.

            Under terms of this task we'll do the following:
            - Derive {{Item_splocal}}, {{Item_splocal_row_field}}, {{Item_user_var_as_out_param}}, and possibly {{Item_trigger_field}} from {{Load_data_outvar}} (added in MDEV-15597).
            - Possibly get rid of {{Item_user_var_as_out_param}} and replace it to {{Item_func_get_user_var}} or {{Item_func_get_user_var}}. This change is optional, we'll decide during development.
            - Possibly change collecting {{LOAD DATA}} targets from {{List<Item>}} to {{List<Load_data_outvar>}}. So in case if we don't remove {{Item_user_var_as_out_param}}, we can at least remove its inheritance from {{Item}} and its useless methods like {{val_str}}, which currently do {{DBUG_ASSERT}}.
            julien.fritsch Julien Fritsch made changes -
            Epic Link MDEV-21071 [ 80504 ]
            julien.fritsch Julien Fritsch made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            Assignee Alexander Barkov [ bar ]
            bar Alexander Barkov made changes -
            Component/s Stored routines [ 13905 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 80972 ] MariaDB v4 [ 130642 ]

            People

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

              Dates

                Created:
                Updated:

                Git Integration

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