Currently MariaDB has a very relaxed function parameter data type control. It's only prohibited to pass a ROW-type value to a function expecting a scalar parameter, or the other way around. The responsible code resides in:
MariaDB has had mostly general purpose data types so far (except GEOMETRY), so the code assumes that all data types implement all value format methods:
Function parameter data type control needs some improvements, because:
- Pluggable data types might not want to implement all value methods. For example, the UUID data type may not want to implement get_date(), as UUID-to-temporal conversion has no any sense.
- Data type plugins might want stricter control on their function parameter data types. For example, the function GEOMEFROMTEXT(txt) returning a GEOMETRY-type value, might want to return an error at fix_fields time on attempts to pass a number (instead of a string) as a parameter txt, because the result will be NULL anyway for all possible numbers.
- After introduction of the ROW-type variables (
MDEV-10914), in some cases it's now not possible to distinguish between a scalar parameter and a ROW value with one element.
Under terms of this task we'll improve function parameter control methods:
- We'll replace Item_func::check_allowed_arg_cols(uint argno)) to a more generic method:
This method will be called from Item_func::fix_fields(), after the loop doing fix_fields() for the arguments.
- As a prove of the concept, we'll fix functions in item_geofunc.h to disallow various senseless function parameter data type combinations. For example, passing a number as a GEOMETRY parameter, or passing a GEOMETRY value as a numeric parameter, will be disallowed.
Note, passing GEOMETRY values to functions implemented outside of item_geofunc.h will still be possible for now, e.g.:
This will be fixed under terms of a separate task.