yashmayya commented on code in PR #17017:
URL: https://github.com/apache/pinot/pull/17017#discussion_r2450019059
##########
pinot-common/src/main/java/org/apache/pinot/common/utils/request/RequestUtils.java:
##########
@@ -664,4 +670,49 @@ public static void applyTimestampIndexOverrideHints(
}
}
}
+
+ /**
+ * Infers the expression type by recursively traversing the expression tree
for function calls. The provided schema
+ * is used to resolve the types for identifier expressions. Note that for
function calls, only scalar functions are
+ * supported here currently. Transform functions that don't have equivalent
scalar functions, and aggregation
+ * functions aren't supported and {@link ColumnDataType#UNKNOWN} will be
returned for them.
+ */
+ @Nullable
+ public static ColumnDataType inferExpressionType(@Nullable Expression
expression, Schema schema) {
+ if (expression == null) {
+ return null;
+ }
+
+ if (expression.isSetIdentifier()) {
+ String columnName = expression.getIdentifier().getName();
+ FieldSpec fieldSpec = schema.getFieldSpecFor(columnName);
+ if (fieldSpec == null) {
+ return ColumnDataType.UNKNOWN;
+ }
+ return ColumnDataType.fromDataType(fieldSpec.getDataType(),
fieldSpec.isSingleValueField());
+ }
+
+ if (expression.isSetLiteral()) {
+ LiteralContext literalContext = new
LiteralContext(expression.getLiteral());
+ return ColumnDataType.fromDataType(literalContext.getType(),
literalContext.isSingleValue());
+ }
+
+ if (expression.isSetFunctionCall()) {
+ Function fn = expression.getFunctionCall();
+ int numOperands = fn.getOperandsSize();
+ ColumnDataType[] argTypes = new ColumnDataType[numOperands];
+ for (int i = 0; i < numOperands; i++) {
+ ColumnDataType argType = inferExpressionType(fn.getOperands().get(i),
schema);
+ argTypes[i] = argType != null ? argType : ColumnDataType.UNKNOWN;
+ }
+ FunctionInfo functionInfo =
FunctionRegistry.lookupFunctionInfo(fn.getOperator(), argTypes);
+ if (functionInfo != null) {
+ Class<?> returnClass = functionInfo.getMethod().getReturnType();
Review Comment:
Yeah that's a good point.
I've given the Calcite based approach a go, but I'm not sure if it's robust
enough to cover all cases TBH. Also, there are gonna be type differences
between MSE and SSE especially for the Calcite standard operators - for
instance, in SSE `abs` always returns `DOUBLE` whereas the standard Calcite
`ABS` operator returns the same type as the operand (so `INT` for `INT` etc.).
--
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]
