clintropolis commented on a change in pull request #11923:
URL: https://github.com/apache/druid/pull/11923#discussion_r765561312
##########
File path:
sql/src/main/java/org/apache/druid/sql/calcite/rule/DruidLogicalValuesRule.java
##########
@@ -110,6 +111,13 @@ static Object getValueFromLiteral(RexLiteral literal,
PlannerContext plannerCont
case SMALLINT:
case INTEGER:
case BIGINT:
+ // Safegaurd in case the internal implementaion of the RexLiteral for
numbers change
+ Object maybeBigDecimalImpl = literal.getValue();
+ if (maybeBigDecimalImpl instanceof BigDecimal) {
+ return ((BigDecimal) maybeBigDecimalImpl).longValue();
+ }
+ // This might return incorrect value if the literal was created from
float.
+ // For example, representation of the form 123.0 can return 1230
Review comment:
I mean we sort of already have to know how the library works to call
`literal.getValueAs(BigDecimal.class)` to get a type we don't want to turn it
into one we do so it doesn't really seem any different to me. This is the only
place we are using `getValueAs` in our code, most other callers use
`RexLiteral.value(...)` which is equivalent to `getValue` for `RexLiteral` but
also allows `CAST` and unary negation functions to get literal values. Most of
those callers appear to be casting the value to `Number` (see
`Expressions.literalToDruidExpression`)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
