amaliujia commented on pull request #13898: URL: https://github.com/apache/beam/pull/13898#issuecomment-780950443
Calcite does more for built-in operators than UDF. Using CAST as an example: https://github.com/apache/calcite/blob/d815dc1209c3cc0728941e9fc81fce7d9e44c79b/core/src/main/java/org/apache/calcite/adapter/enumerable/RexToLixTranslator.java#L248 . For UDF, fortunately, Calcite does less. Basically Calcite will either generate the string representation of a value (i.e. Literal) or make a Row field access (i.e. column), and then make a reflection call on the UDF implementation. So for UDF, I think we only need to verify 1) whether Calcite does anything that make the value lose precision 2) whether Calcite generates a correct string representation for value or make correct field access to Row. The verification work will be much less compared to checking the built-in operators. I agree this PR could be an upper bound for the limitation of Java UDF, what I want to see is whether we can do better. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
