tustvold commented on issue #6828:
URL:
https://github.com/apache/arrow-datafusion/issues/6828#issuecomment-1619044019
Interestingly duckdb appears to not support decimal division at all
```
>>> duckdb.sql('select cast(5 as DECIMAL(38, 10)) / cast(10 as DECIMAL(38,
10))')
┌──────────────────────────────────────────────────────────┐
│ (CAST(5 AS DECIMAL(38,10)) / CAST(10 AS DECIMAL(38,10))) │
│ double │
├──────────────────────────────────────────────────────────┤
│ 0.5 │
└──────────────────────────────────────────────────────────┘
```
Mysql appears to just increment the left hand scale by 4
```
DECIMAL(38, 10) / DECIMAL(38, 10) -> DECIMAL(52, 14)
DECIMAL(11, 10) / DECIMAL(2, 0) -> DECIMAL(15, 14)
DECIMAL(11, 10) / DECIMAL(13, 12) -> DECIMAL(27, 14)
DECIMAL(11, 10) / DECIMAL(17, 16) -> DECIMAL(31, 14)
```
Postgres appears to do something similar -
https://github.com/postgres/postgres/blob/29cf61ade3f245aa40f427a1d6345287ef77e622/src/interfaces/ecpg/pgtypeslib/numeric.c#L1047
Interestingly the [Hive
specification](https://cwiki.apache.org/confluence/download/attachments/27362075/Hive_Decimal_Precision_Scale_Support.pdf)
states
> But one thing is clear, for scale resulting from a division, the scale of
the result is s1 plus a
system-wide increment, which has a default 4
But then goes on to show a table with something different
I think using a fixed increment of the dividends precision makes a whole lot
more sense than a value computed based on the right hand sides precision, which
just seems to be a recipe for overflow.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
