Uploaded image for project: 'MariaDB ColumnStore'
  1. MariaDB ColumnStore
  2. MCOL-5215

UNION on DECIMAL returns incorrect results

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • 23.02.1
    • PrimProc
    • None

    Description

      Here is an example SQL script with wrong outputs when UNOIN of MCS computes with DECIMAL with 38 digits precision when the precision is saturated.

      An example wrong case is a UNION with DECIMAL(38) and DECIMAL(38,38). The result type in the system is a DECIMAL(38,38), which is wrong and can not represent any number with digits before the `.`.

      SET default_storage_engine=ColumnStore;
      CREATE TABLE t1 (a DECIMAL(38), b DECIMAL(38,10), c DECIMAL(38,38));
      INSERT INTO t1 VALUES (-125, -1.25, -0.125);
      SELECT * FROM (SELECT a FROM t1 UNION ALL SELECT c FROM t1) tu ORDER BY a
      

      +-------------------------------------------+
      | a                                         |
      +-------------------------------------------+
      | -0.12500000000000000000000000000000000000 |
      |  0.90447576074723148144860474975423823872 |
      +-------------------------------------------+
      2 rows in set (0.031 sec)
      

      The correct behaviour is to throw a warning when the precision of DECIMAL is saturated. However, there are some cases to be discussed.

      Attachments

        Issue Links

          Activity

            People

              tntnatbry Gagan Goel (Inactive)
              Jigao Luo Jigao Luo
              Gagan Goel Gagan Goel (Inactive)
              Daniel Lee Daniel Lee (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.