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

Fix Item_param::basic_const_item() to return true for temporal bound values

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.3(EOL)
    • 10.4(EOL)
    • Data types
    • None

    Description

      There is an asymmetry for temporal data types in Item_param:

      bool Item_param::basic_const_item() const
      		 
      {
      		 
        DBUG_ASSERT(fixed || state == NO_VALUE);
      		 
        if (state == NO_VALUE ||
      		 
            (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
      		 
          return FALSE;
      		 
        return TRUE;
      		 
      }

      Notice, unlike for other data types, basic_const_item() returns false for bound temporal values.

      The reason for this was probably because prior to 10.0 we didn't have Item_temporal_literal (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
      Now this asymmetry can be fixed, so Item_param::clone_item() returns non-NULL values for all data types.

      This asymmetry affects negatively various aspects, for example, constant propagation may not work as efficient, as for other data types.

      Also, in this example:

      EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';

      the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

      For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:

      EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;

      In this example, the default integer value 10 is stored in the FRM as an expression rather than a constant.

      Attachments

        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 -
          Description There is an asymmetry in temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          the default value is stored in the FRM as an expression rather than a constant.

          		There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          the default value is stored in the FRM as an expression rather than a constant.

          bar Alexander Barkov made changes -
          Description There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          the default value is stored in the FRM as an expression rather than a constant.

          		There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value is stored in the FRM as an expression rather than a constant.

          bar Alexander Barkov made changes -
          Description There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value is stored in the FRM as an expression rather than a constant.

          		There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          bar Alexander Barkov made changes -
          Description There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} return non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          		There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} returns non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          bar Alexander Barkov made changes -
          Description There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} returns non-NULL value for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          		There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} returns non-NULL values for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          bar Alexander Barkov made changes -
          Description There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} returns non-NULL values for all data types.

          This asymmetry affects negatively various aspects, for example, disables constant propagation.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          		There is an asymmetry for temporal data types in Item_param:

          {code:cpp}
          bool Item_param::basic_const_item() const
          {
            DBUG_ASSERT(fixed || state == NO_VALUE);
            if (state == NO_VALUE ||
                (state == SHORT_DATA_VALUE && type_handler()->cmp_type() == TIME_RESULT))
              return FALSE;
            return TRUE;
          }
          {code}
          Notice, unlike for other data types, {{basic_const_item()}} returns {{false}} for bound temporal values.

          The reason for this was probably because prior to {{10.0}} we didn't have {{Item_temporal_literal}} (and its descendants) so that Item_param::clone_item() could not return a basic constant for temporal values.
          Now this asymmetry can be fixed, so {{Item_param::clone_item()}} returns non-NULL values for all data types.

          This asymmetry affects negatively various aspects, for example, constant propagation may not work as efficient, as for other data types.


          Also, in this example:

          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a TIME DEFAULT ?)' USING TIME'10:10:10';
          {code}
          the default value is stored in the FRM as an expression rather than a constant (its visible if one opens the frm in a text editor).

          For non-temporal data types, Item_param used in DEFAULT clause is converted to constants, e.g.:
          {code:sql}
          EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING 10;
          {code}
          In this example, the default integer value {{10}} is stored in the FRM as an expression rather than a constant.

          bar Alexander Barkov made changes -
          Component/s Data types [ 13906 ]
          bar Alexander Barkov made changes -
          Affects Version/s 10.3 [ 22126 ]
          bar Alexander Barkov made changes -
          Fix Version/s 10.4 [ 22408 ]
          Fix Version/s 10.3 [ 22126 ]
          julien.fritsch Julien Fritsch made changes -
          Epic Link MDEV-21071 [ 80504 ]
          julien.fritsch Julien Fritsch made changes -
          julien.fritsch Julien Fritsch made changes -
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 86264 ] MariaDB v4 [ 140709 ]

          People

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

            Dates

              Created:
              Updated:

              Git Integration

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