Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
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:
virtual Item_func::check_allowed_arg_cols(uint argno);
|
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:
- val_int()
- val_real()
- val_decimal()
- val_str()
- get_date()
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:
virtual bool check_arguments() const;
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.:
SELECT TIMEDIFF(POINT(1,1)); |
This will be fixed under terms of a separate task.
Attachments
Issue Links
- blocks
-
MDEV-4912 Data type plugin API version 1
-
- Closed
-
- relates to
-
MDEV-13964 Parameter data type control for Item_real_func
-
- Closed
-
-
MDEV-13965 Parameter data type control for Item_longlong_func
-
- Closed
-
-
MDEV-13966 Parameter data type control for Item_temporal_func
-
- Closed
-
-
MDEV-13967 Parameter data type control for Item_long_func
-
- Closed
-
Activity
Status | Open [ 1 ] | In Progress [ 3 ] |
Assignee | Alexander Barkov [ bar ] | Alexey Botchkov [ holyfoot ] |
Status | In Progress [ 3 ] | In Review [ 10002 ] |
Description |
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:
{code:code} virtual Item_func::check_allowed_arg_cols(uint argno); {code} 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: - {{val_int()}} - {{val_real()}} - {{val_decimal()}} - {{val_str()}} - {{get_date()}} 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 ( 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: {code:cpp} virtual bool check_arguments() const; {code} 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.: {code:sql} SELECT TIMEDIFF(POINT(1,1)); {code} This will be fixed under terms of a separate task. |
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:
{code:code} virtual Item_func::check_allowed_arg_cols(uint argno); {code} 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: - {{val_int()}} - {{val_real()}} - {{val_decimal()}} - {{val_str()}} - {{get_date()}} 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 ( 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: {code:cpp} virtual bool check_arguments() const; {code} 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.: {code:sql} SELECT TIMEDIFF(POINT(1,1)); {code} This will be fixed under terms of a separate task. |
Assignee | Alexey Botchkov [ holyfoot ] | Alexander Barkov [ bar ] |
Status | In Review [ 10002 ] | Stalled [ 10000 ] |
issue.field.resolutiondate | 2017-05-29 06:31:49.0 | 2017-05-29 06:31:49.26 |
Fix Version/s | 10.3.1 [ 22532 ] | |
Fix Version/s | 10.3 [ 22126 ] | |
Resolution | Fixed [ 1 ] | |
Status | Stalled [ 10000 ] | Closed [ 6 ] |
Link |
This issue relates to |
Link |
This issue relates to |
Link |
This issue relates to |
Link |
This issue relates to |
Workflow | MariaDB v3 [ 80772 ] | MariaDB v4 [ 133254 ] |