[MCOL-4647] SEC_TO_TIME(double_or_float) returns a wrong result Created: 2021-03-29  Updated: 2021-04-05  Resolved: 2021-04-05

Status: Closed
Project: MariaDB ColumnStore
Component/s: PrimProc
Affects Version/s: 5.6.1, 6.1.1
Fix Version/s: 6.1.1

Type: Bug Priority: Major
Reporter: Alexander Barkov Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
blocks MCOL-4361 Replace pow(10.0, (double)scale) expr... Closed
Relates
relates to MCOL-4651 SEC_TO_TIME(hugePositiveDecimal) retu... Closed
Sprint: 2021-5

 Description   

This problem is repeatable with both DOUBLE and FLOAT data types:

DROP TABLE IF EXISTS t1;
 
CREATE TABLE t1 (a DOUBLE) ENGINE=ColumnStore;
 
INSERT INTO t1 VALUES (0.000025e-35);
 
SELECT a, SEC_TO_TIME(a) FROM t1;


+---------+------------------+
 
| a       | SEC_TO_TIME(a)   |
 
+---------+------------------+
 
| 2.5e-40 | -00:00:01.000000 |
 
+---------+------------------+

Looks wrong. The expected result is:

DROP TABLE IF EXISTS t1;
 
CREATE TABLE t1 (a DOUBLE) ENGINE=InnoDB;
 
INSERT INTO t1 VALUES (0.000025e-35);
 
SELECT a, SEC_TO_TIME(a) FROM t1;


+---------+-----------------+
 
| a       | SEC_TO_TIME(a)  |
 
+---------+-----------------+
 
| 2.5e-40 | 00:00:00.000000 |
 
+---------+-----------------+

The problem is in this piece of the code in func_sec_to_time.cpp:

        case execplan::CalpontSystemCatalog::DOUBLE:
 
        {
 
            const string& valStr = parm[0]->data()->getStrVal(row, isNull);
 
            val = parm[0]->data()->getIntVal(row, isNull);
 
            size_t x = valStr.find(".");
 
 
 
            if (x < string::npos)
 
            {
 
                string tmp = valStr.substr(x + 1, 1);
 
                char* ptr = &tmp[0];
 
                int i = atoi(ptr);
 
 
 
                if (i >= 5)
 
                {
 
                    if (val > 0)
 
                        val += 1;
 
                    else
 
                        val -= 1;
 
                }
 
            }
 
        }

It searches for the DOT character assuming that fractional digits go after it. But this is not the case for scientific notation like 2.5e-40.
Generated at Thu Feb 08 02:51:56 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.