abhishekagarwal87 commented on a change in pull request #10370:
URL: https://github.com/apache/druid/pull/10370#discussion_r488075026
##########
File path:
core/src/main/java/org/apache/druid/math/expr/BinaryLogicalOperatorExpr.java
##########
@@ -57,6 +57,17 @@ protected final double evalDouble(double left, double right)
// Use Double.compare for more consistent NaN handling.
return Evals.asDouble(Double.compare(left, right) < 0);
}
+
+ @Nullable
+ @Override
+ public ExprType getOutputType(InputBindingTypes inputTypes)
+ {
+ ExprType implicitCast = super.getOutputType(inputTypes);
+ if (ExprType.STRING.equals(implicitCast)) {
+ return ExprType.LONG;
+ }
+ return implicitCast;
Review comment:
can you elaborate more on this? How will that look like?
> This PR is setting up for vectorized expressions, which are going to be
strongly typed before processing, which I think makes this
inconsistent/confusing/magical behavior not necessary.
While I understand the right behavior is debatable, it may still be best to
keep the type in sync with eval even if it's not very intuitive. It may require
that the logic of figuring out the type is not reusable as a function
`ExprType.autoTypeConversion` and may have to be written differently for some
operators. We can, later on, change the different functions, fixing both the
`eval` and `getOutputType` together. But till then, they will be in sync.
----------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
