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

Split Item_temporal_func::fix_length_and_dec()

Details

    Description

      We're anticipating the following additions and changes soon:

      • MDEV-12513 INTERVAL data type
      • MDEV-10018 Timestamp with time zone
      • Hybrid functions like COALESCE will be able to return values of the new data types (including INTERVAL and TIMESTAMP WITH TIME ZONE, so the Item API will be extended with some new method to fetch native representations of these data types: 

        virtual bool get_value(Value *value);

        where Value will be a new class, most likely based on struct st_value.

      • Functions CONVERT_TZ() and TIMEDIFF() will support TIMESTAMP WITH TIME ZONE, so they will become hybrid type functions rather than fixed type functions.
      • The function STR_TO_DATE will be extended to detect time zone formats and set its return type to TIMESTAMP WITH TIME ZONE when applicable.

      The intent of this task is to make item_timefunc.h and item_timefunc.cc more ready for the mentioned tasks. This task will include the following changes:

      1. The key point is to get rid of the generic Item_temporal_func::fix_length_and_dec and particular of this code:

      uint char_length= mysql_temporal_int_part_length(field_type());

      which is not friendly to adding new data types.

      • The code related to calculating the length of the integer part will migrate to fix_length_and_dec() implementations of individual Item_temporal_func descendants.
      • The code related to calculating "decimals" will migrate as a new method Type_str_attributes.

      2. The classes Item_date_add_interval, Item_func_add_time, Item_func_str_to_date (implementing temporal hybrid functions DATE_ADD(), ADD_TIME(), STR_TO_DATE()) will become descendants of Item_hybrid_func, so later we can add support for the INTERVAL and TIMESTAMP WITH TIME ZONE data types easier, e.g. reuse the get_value() related infrastructure. In order to do this we'll derive Item_temporal_hybrid_func from Item_hybrid_func rather than Item_temporal_func.

      Note, in the current implementation, Item_temporal_hybrid_func descendants use the inherited method Item_temporal_func::save_in_field() which uses save_date_in_field() even if the return data type is VARCHAR. This is wrong. See MDEV-12515. When we move Item_temporal_hybrid_func to Item_hybrid_func, this bug should automatically be gone, as this change will make Item_temporal_hybrid_func use the inherited method Item_hybrid_func::save_in_field() instead, which handles all data types (including VARCHAR) more precisely.

      3. The function mysql_temporal_int_part_length() will be removed.

      4. Expressions of the GEOMETRY type (and its variants such as POINT) will be disallowed as arguments to DATE_ADD(), ADDTIME() and STR_TO_DATE(). This will be a similar change to those that we earlier did for other hybrid functions (e.g. in MDEV-12238, MDEV-11478). Note, we however won't add these members to Type_handler_data at this point:

      Type_aggregator m_type_aggregator_for_date_add;
      		 
      Type_aggregator m_type_aggregator_for_addtime;
      		 
      Type_aggregator m_type_aggregator_for_str_to_date;

      They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with GEOMETRY being the only one non-traditional type at this point).

      Attachments

        Issue Links

          blocks

          Epic - Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down. MDEV-4912 Data type plugin API version 1

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          New Feature - A new feature of the product, which has yet to be developed. MDEV-10018 Timestamp with time zone

          • Major - Major loss of function.
          • Open

          New Feature - A new feature of the product, which has yet to be developed. MDEV-12513 INTERVAL data type

          • Major - Major loss of function.
          • Open
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12515 Wrong value when storing DATE_ADD() and ADDTIME() to a numeric field

          • 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 -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}} and {{ADDTIME()}}.
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}.
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}.
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear.
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear.
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as it will make {{Item_temporal_hybrid_func}} use the inherited {{Item_hybrid_func::save_in_field()}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as it will make {{Item_temporal_hybrid_func}} use the inherited {{Item_hybrid_func::save_in_field()}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as it will make {{Item_temporal_hybrid_func}} use the inherited {{Item_hybrid_func::save_in_field()}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as it will make {{Item_temporal_hybrid_func}} use the inherited {{Item_hybrid_func::save_in_field()}}.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as it will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as it will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. Note, we won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. This will be a similar change to those that we earlier did for other hybrid functions (e.g.MDEV-12238, MDEV-11478). Note, we however won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. This will be a similar change to those that we earlier did for other hybrid functions (e.g.MDEV-12238, MDEV-11478). Note, we however won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. This will be a similar change to those that we earlier did for other hybrid functions (e.g. in MDEV-12238, MDEV-11478). Note, we however won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            Description We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. This will be a similar change to those that we earlier did for other hybrid functions (e.g. in MDEV-12238, MDEV-11478). Note, we however won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            		We're anticipating the following additions and changes soon:
            - MDEV-12513 INTERVAL data type
            - MDEV-10018 Timestamp with time zone
            - Hybrid functions like {{COALESCE}} will be able to return values of the new data types (including {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}}, so the {{Item}} {{API}} will be extended with some new method to fetch native representations of these data types:
            {code:cpp}
            virtual bool get_value(Value *value);
            {code}
            where {{Value}} will be a new class, most likely based on {{struct st_value}}.
            - Functions CONVERT_TZ() and TIMEDIFF() will support {{TIMESTAMP WITH TIME ZONE}}, so they will become hybrid type functions rather than fixed type functions.
            - The function {{STR_TO_DATE}} will be extended to detect time zone formats and set its return type to {{TIMESTAMP WITH TIME ZONE}} when applicable.

            The intent of this task is to make {{item_timefunc.h}} and {{item_timefunc.cc}} more ready for the mentioned tasks. This task will include the following changes:

            1. The key point is to get rid of the generic {{Item_temporal_func::fix_length_and_dec}} and particular of this code:
            {code:cpp}
            uint char_length= mysql_temporal_int_part_length(field_type());
            {code}
            which is not friendly to adding new data types.
            - The code related to calculating the length of the integer part will migrate to {{fix_length_and_dec()}} implementations of individual {{Item_temporal_func}} descendants.
            - The code related to calculating "decimals" will migrate as a new method {{Type_str_attributes}}.

            2. The classes {{Item_date_add_interval}}, {{Item_func_add_time}}, {{Item_func_str_to_date}} (implementing temporal hybrid functions {{DATE_ADD()}}, {{ADD_TIME()}}, {{STR_TO_DATE()}}) will become descendants of {{Item_hybrid_func}}, so later we can add support for the {{INTERVAL}} and {{TIMESTAMP WITH TIME ZONE}} data types easier, e.g. reuse the {{get_value()}} related infrastructure. In order to do this we'll derive {{Item_temporal_hybrid_func}} from {{Item_hybrid_func}} rather than {{Item_temporal_func}}.

            Note, in the current implementation, {{Item_temporal_hybrid_func}} descendants use the inherited method {{Item_temporal_func::save_in_field()}} which uses {{save_date_in_field()}} even if the return data type is {{VARCHAR}}. This is wrong. See MDEV-12515. When we move {{Item_temporal_hybrid_func}} to {{Item_hybrid_func}}, this bug should automatically be gone, as this change will make {{Item_temporal_hybrid_func}} use the inherited method {{Item_hybrid_func::save_in_field()}} instead, which handles all data types (including {{VARCHAR}}) more precisely.

            3. The function {{mysql_temporal_int_part_length()}} will be removed.

            4. Expressions of the {{GEOMETRY}} type (and its variants such as {{POINT}}) will be disallowed as arguments to {{DATE_ADD()}}, {{ADDTIME()}} and {{STR_TO_DATE()}}. This will be a similar change to those that we earlier did for other hybrid functions (e.g. in MDEV-12238, MDEV-11478). Note, we however won't add these members to {{Type_handler_data}} at this point:
            {code:cpp}
            Type_aggregator m_type_aggregator_for_date_add;
            Type_aggregator m_type_aggregator_for_addtime;
            Type_aggregator m_type_aggregator_for_str_to_date;
            {code}
            They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with {{GEOMETRY}} being the only one non-traditional type at this point).
            bar Alexander Barkov made changes -
            issue.field.resolutiondate 2017-04-19 02:08:10.0 2017-04-19 02:08:10.87
            bar Alexander Barkov made changes -
            Fix Version/s 10.3.1 [ 22532 ]
            Fix Version/s 10.3 [ 22126 ]
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 80339 ] MariaDB v4 [ 133209 ]

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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