Github user HyukjinKwon commented on the pull request:
https://github.com/apache/spark/pull/8718#issuecomment-141960719
It looks the original case became a downcast `Decimal(10, 0)` to
`Decimal(7, 2)` which seems when scale and precision of the latter are less
than the former, rather than int to decimal. I think there have been an update
at Optimizer.
It looks roughly in most cases, the conversions need to be downcasted.
Here is a list i tested.
1. Where `A` is `IntegerType`
`WHERE A <= 2500` becomes int to int
`WHERE A <= 2500.0` becomes decimal(11, 1) to decimal(10, 0)
2. Where `A` is `Decimal(7,2)`
`WHERE A <= 2500` becomes decimal(10, 0) to decimal(7, 2)
`WHERE A <= 2500.0` becomes decimal(7, 2) to decimal(7, 2)
`WHERE A <= 2500.00` becomes decimal(12, 2) to decimal(7, 2)
3. Where `A` is `Double`
`WHERE A <= 2500` becomes double to double
`WHERE A <= 2500.0` becomes double to double
So I think even if I check the widening cast dealing with types and both
precision and scale in `Decimal`, neither this issue can be resolved nor deals
with a lot of use-cases.
I'm not too sure if
1. I should just go for this
2. handles only numbers including downcasts with `Cast(...).eval()`, or
3. just close this.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
