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:
But its not possible to do inside a stored routine:
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
- 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.