Repository navigation
scalar function round ignores second parameter #4191
Description
Describe the bug
round accepts two arguments, but is also defined as a unary function. The second parameter is ignored.
❯ select round(3.141592, 0);
+-----------------------------------+
| round(Float64(3.141592),Int64(0)) |
+-----------------------------------+
| 3 |
+-----------------------------------+
1 row in set. Query took 0.000 seconds.
❯ select round(3.141592, -2);
+------------------------------------+
| round(Float64(3.141592),Int64(-2)) |
+------------------------------------+
| 3 |
+------------------------------------+
1 row in set. Query took 0.000 seconds.
❯ select round(3.141592, 2);
+-----------------------------------+
| round(Float64(3.141592),Int64(2)) |
+-----------------------------------+
| 3 |
+-----------------------------------+
1 row in set. Query took 0.000 seconds.
To Reproduce
See above
Expected behavior
I expect the behavior to be consistent with Postgres round(v numeric, s int). User guide will also need updating.
Additional context
Related to #2420
Activity
HaoYang670 commentedon Nov 15, 2022
Not sure, but I wonder if we could support this in logical phase.
Given the following 2 lemmas:
we can unfold the
roundfunction in the logical plan stage and don't need to modify the physical stage.One concern here is that
Decimaltype might be better thanFloattype because we've found some corner cases in floating point multiplication and division: #4072DDtKey commentedon Jan 22, 2023
Just wondering if anyone is working on it? It's relevant for current version. I see the same behaviour
HaoYang670 commentedon Jan 22, 2023
I've pushed a draft PR (#4234) to unfold the
roundfunction with 2 args in logical plan.But it seems like not a good solution because it would reduce the extensibility of the logical optimizer.
Based on Andy's comment (#4234 (comment)) we should either support this or return an error in the physical plan.
No, I guess.