scalar function round ignores second parameter

[andygrove]

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

[HaoYang670]

Not sure, but I wonder if we could support this in logical phase.
Given the following 2 lemmas:

1. forall source: FloatArray, round(source) = round(source, 0)
2. forall source: FloatArray n: IntArray | IntScalar,
        round(source, n) = div(
                              round(mul(
                                      source, 
                                      pow(10, n))), 
                              pow(10, n))

we can unfold the round function in the logical plan stage and don't need to modify the physical stage.

One concern here is that Decimal type might be better than Float type because we've found some corner cases in floating point multiplication and division: #4072

[DDtKey]

Just wondering if anyone is working on it? It's relevant for current version. I see the same behaviour

[HaoYang670]

I've pushed a draft PR (#4234) to unfold the round function 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.

Just wondering if anyone is working on it?

No, I guess.