1
0
mirror of https://github.com/MariaDB/server.git synced 2025-06-04 18:03:14 +03:00

6 Commits

Author SHA1 Message Date
Alexander Barkov
6426b52ed4 MDEV-15957 Unexpected "Data too long" when doing CREATE..SELECT with stored func
Problems:

1. Unlike Item_field::fix_fields(),
  Item_sum_sp::fix_length_and_dec() and Item_func_sp::fix_length_and_dec()
  did not run the code which resided in adjust_max_effective_column_length(),
  therefore they did not extend max_length for the integer return data types
  from the user-specified length to the maximum length according to
  the data type capacity.

2. The code in adjust_max_effective_column_length() was not correct
   for TEXT data, because Field_blob::max_display_length()
   multiplies to mbmaxlen. So TEXT variants were unintentionally
   promoted to the next longer data type for multi-byte character
   sets: TINYTEXT->TEXT, TEXT->MEDIUMTEXT, MEDIUMTEXT->LONGTEXT.

3. Item_sum_sp::create_table_field_from_handler()
   Item_func_sp::create_table_field_from_handler()
   erroneously called tmp_table_field_from_field_type(),
   which converted VARCHAR(>512) to TEXT variants.
   So "CREATE..SELECT spfunc()" erroneously converted
   VARCHAR to TEXT. This was wrong, because stored
   functions have explicitly declared data types,
   which should be preserved.

Solution:

- Removing Type_std_attributes(const Field *)
  and using instead Type_std_attributes::set() in combination
  with field->type_str_attributes() all around the code, e.g.:
     Type_std_attributes::set(field->type_std_attributes())

  These two ways of copying attributes from a Field
  to an Item duplicated each other, and were slightly
  different in how to mix max_length and mbmaxlen.

- Removing adjust_max_effective_column_length() and
  fixing Field::type_std_attributes() to do all necessary
  type-specific calculations , so no further adjustments
  is needed.
  Field::type_std_attributes() is now called from all affected methods:
   Item_field::fix_fields()
   Item_sum_sp::fix_length_and_dec()
   Item_func_sp::fix_length_and_dec()
  This fixes the problem N1.

- Making Field::type_std_attributes() virtual, to make
  sure that type-specific adjustments a properly done
  by individual Field_xxx classes. Implementing
  Field_blob::type_std_attributes() in the way that
  no TEXT promotion is done.
  This fixes the problem N2.

- Fixing Item_sum_sp::create_table_field_from_handler()
  Item_func_sp::create_table_field_from_handler() to
  call create_table_field_from_handler() instead of
  tmp_table_field_from_field_type() to avoid
  VARCHAR->TEXT conversion on "CREATE..SELECT spfunc()".

- Recording mysql-test/suite/compat/oracle/r/sp-param.result
  as "CREATE..SELECT spfunc()" now correctly
  preserve the data type as specified in the RETURNS clause.

- Adding new tests
2018-04-23 09:31:17 +04:00
Jerome Brauge
d943d7f712 MDEV-13417 UPDATE produces wrong values if an updated column is later used as an update source
Standard compatible behavior for UPDATE: all assignments in SET
are executed "simultaneously", not left-to-right. And `SET a=b,b=a`
will swap the values.
2018-02-12 13:14:23 +01:00
Alexander Barkov
003cb2f424 Merge remote-tracking branch 'origin/10.2' into bb-10.2-ext 2017-10-30 16:42:46 +04:00
Alexander Barkov
c9a01420cf Additional tests for MDEV-13919 sql_mode=ORACLE: Derive length of VARCHAR... 2017-09-28 11:05:27 +04:00
halfspawn
f44d5de689 MDEV-13919 sql_mode=ORACLE: Derive length of VARCHAR SP parameters with no length from actual parameters 2017-09-27 16:49:40 +02:00
Alexander Barkov
02a72cf87c MDEV-10596 Allow VARCHAR and VARCHAR2 without length as a data type of routine parameters and in RETURN clause 2017-04-05 15:02:49 +04:00