bug:A table of type DECIMAL, inserting a maximum value, displayed as 0

[422351990]

Describe the problem
A table of type DECIMAL, inserting a maximum value, displayed as 0

Expected behavior
The expected values are 9999999999999999999999999999.9999999999、-9999999999999999999999999999.9999999999

How To Reproduce
Execute to create tables of type DECIMAL

Create Table: CREATE TABLE `TYPE008` (
  `COL` decimal(18,10) DEFAULT NULL
) ENGINE=STONEDB DEFAULT CHARSET=utf8

Perform the maximum value of the insert DECIMAL (38,10) type.
Perform insert minimum values of type DECIMAL (38,10)

INSERT INTO TYPE008 VALUES(99999999.9999999999);
INSERT INTO TYPE008 VALUES(-99999999.9999999999);
SELECT * FROM TYPE008;

Environment
Ubuntu 20.04.4 LTS
Server version: 5.6.24-StoneDB

Additional context
none

[hustjieke]

FIx it in stonedb-5.7 first.

[swoapri]

Stonedb decimal bug fix && support completely "decimal data type":

- Problem Description:

This problem is because when the bottom layer of stonedb stores the type of decimal, it needs to convert the decimal into int64_t type storage according to the scale parameter. In the process of conversion, the my_strtod() function is used, resulting in loss of precision.

The precision range problem, because the bottom layer uses int64_t storage, the precision range is limited to 18 bits, which is less than the 65 bits of the decimal data type supported by innodb.

- Current solution:

Encoding and storage: stonedb supports two storage types, PackInt and PackStr. At present, the storage scheme of PackStr can be used, and the encoding scheme of decimal of innodb is adopted: convert to Fixed Binary String <my_decimal2binary>, and the bottom layer is stored in binary string.

Operator, aggregation function adaptation in stonedb: read binary string from the bottom layer, convert it to decimal type, and support operations such as decimal type comparison. Various operators, functions, and operators of stonedb need to support the decimal type.

Any Questions?