[MDEV-13997] Change Item_bool_rowready_func2 to cache const items at fix time rather than evaluation time - Jira

Details

Type: Task
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Fix Version/s: 10.3.3
Component/s: Data types, Temporal Types
Labels:
None

Sprint:
10.3.3-1

Description

Currently there is an asymmetry in how binary comparison operators (such as = or >, etc) are implemented for temporal vs other data types.

Item_bool_rowready_func2 does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of Item_cache_temporal at evaluation time, when get_datetime_value() is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in Arg_comparator::set_cmp_func_(string|int|real|decimals)(), with these two lines:

  a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());

  b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using cache_converted_constant(), like it is done for the other data types. Caching during evaluation time will be removed.

Rationale:

We're adding pluggable data types soon. It's better to have symmetric code, to add new data types easier.
TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME (such conversion can be lossy, see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Attachments

Issue Links

blocks

MDEV-4912 Data type plugin API version 1

Closed

MDEV-13995 MAX(timestamp) returns a wrong result near DST change

Closed

Activity

Ascending order - Click to sort in descending order

Alexander Barkov created issue - 2017-10-04 10:14

Alexander Barkov made changes - 2017-10-04 10:15

Field	Original Value	New Value
Link		This issue blocks ~~MDEV-13995~~ [ ~~MDEV-13995~~ ]

Alexander Barkov made changes - 2017-10-04 10:15

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_tempora}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching.

Substitution is done in Arg_comparator::set_cmp_func_{string|int|real|decimals}(), with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching.

Substitution is done in Arg_comparator::set_cmp_func_{string|int|real|decimals}(), with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Alexander Barkov made changes - 2017-10-04 10:16

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching.

Substitution is done in Arg_comparator::set_cmp_func_{string|int|real|decimals}(), with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching.

Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Alexander Barkov made changes - 2017-10-04 10:16

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching.

Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Alexander Barkov made changes - 2017-10-04 10:17

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, like it is done for the other types do.
Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other types do. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Alexander Barkov made changes - 2017-10-04 10:19

Link

This issue blocks ~~MDEV-4912~~ [ ~~MDEV-4912~~ ]

Alexander Barkov made changes - 2017-10-04 11:15

Status

Open [ 1 ]

In Progress [ 3 ]

Alexander Barkov made changes - 2017-10-04 11:15

Assignee	Alexander Barkov [ bar ]	Sergei Golubchik [ serg ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Alexander Barkov made changes - 2017-10-04 11:26

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other types do. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other data types. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Alexander Barkov made changes - 2017-10-04 11:26

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other data types. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data type soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other data types. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data types soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Alexander Barkov made changes - 2017-10-04 11:27

Description

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other data types. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data types soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME, which can be lossy (see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Currently there is an asymmetry in how binary comparison operators (such as {{=}} or {{>}}, etc) are implemented for temporal vs other data types.

{{Item_bool_rowready_func2}} does not cache its constant arguments of temporal types at fix time. Instead, constant arguments are replaced to instances of {{Item_cache_temporal}} at evaluation time, when {{get_datetime_value()}} is executed for the first time.

Non-temporal types do it in a different way: constant arguments are cached at fix time, while the evaluation time code does not do any argument substitution or caching. Substitution is done in {{Arg_comparator::set_cmp_func_(string|int|real|decimals)()}}, with these two lines:
{code:sql}
a= cache_converted_constant(thd, a, &a_cache, compare_type_handler());
b= cache_converted_constant(thd, b, &b_cache, compare_type_handler());
{code}

Under terms of this task we will change the code for the temporal data types to cache constant arguments in fix time, using {{cache_converted_constant()}}, like it is done for the other data types. Caching during evaluation time will be removed.

Rationale:

- We're adding pluggable data types soon. It's better to have symmetric code, to add new data types easier.
- TIMESTAMP should be fixed to do comparison in my_time_t format internally, without conversion to MYSQL_TIME (such conversion can be lossy, see ~~MDEV-13995~~). It would be nice to make the code symmetric before fixing bugs like ~~MDEV-13995~~, for simplicity.

Sergei Golubchik made changes - 2017-10-24 16:45

Sprint

10.3.3-1 [ 200 ]

Sergei Golubchik made changes - 2017-10-26 17:16

Assignee	Sergei Golubchik [ serg ]	Alexander Barkov [ bar ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Alexander Barkov made changes - 2017-10-27 18:08

Assignee	Alexander Barkov [ bar ]	Sergei Golubchik [ serg ]
Status	Stalled [ 10000 ]	In Review [ 10002 ]

Sergei Golubchik made changes - 2017-10-29 18:51

Assignee	Sergei Golubchik [ serg ]	Alexander Barkov [ bar ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Alexander Barkov made changes - 2017-10-30 08:44

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Alexander Barkov made changes - 2017-10-30 08:44

Fix Version/s		10.3.3 [ 22644 ]
Fix Version/s	10.3 [ 22126 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:23

Workflow

MariaDB v3 [ 82915 ]

MariaDB v4 [ 133360 ]

People

Assignee:: Alexander Barkov

Reporter:: Alexander Barkov

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Dates

Created:: 2017-10-04 10:14

Updated:: 2017-10-30 08:44

Resolved:: 2017-10-30 08:44

Git Integration

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

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration