tindzk commented on PR #3687: URL: https://github.com/apache/calcite/pull/3687#issuecomment-1985814301
After checking the referenced code I am not sure whether the issue can be fixed in Avatica. In order to perform type coercion, the target type needs to be known which does not seem to be the available there. Without this information, we also cannot check for overflows. Note that type conversions are already happening in `RexToLixTranslator` as part of the `EnumUtils.convert()` call. The main contribution of my PR is to correctly convert numeric types to the expected target type. Currently, these conversions are failing due to a Java limitation that prevents numeric object types (`java.lang.Long` etc.) from being [directly cast](https://mkyong.com/java/java-lang-classcastexception-class-java-lang-integer-cannot-be-cast-to-class-java-lang-long/) to another numeric type. This is solved by first deriving a primitive `long` (not `Long`) value that can then be safely cast to the target type. This indirection does require an additional check because the object on which `longValue()` gets called may be null. I have not been able to find a simpler workaround for this Java limitation. The remaining changes are unrelated to the reported issue and fix tests that were requested during the PR review, notably passing values to `numeric(N)` placeholders, and preventing overflows that could arise in the conversion process above. I also expect that `convertChecked()` will be replaced by Mihai's implementation after https://github.com/apache/calcite/pull/3589 has been merged which will increase the type coverage. -- 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: commits-unsubscr...@calcite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
