clintropolis commented on a change in pull request #12078:
URL: https://github.com/apache/druid/pull/12078#discussion_r780232347
##########
File path: core/src/main/java/org/apache/druid/math/expr/Function.java
##########
@@ -2994,8 +2994,14 @@ public ExprEval apply(List<Expr> args,
Expr.ObjectBinding bindings)
Object[] out = new Object[length];
ExpressionType arrayType = null;
+
for (int i = 0; i < length; i++) {
ExprEval<?> evaluated = args.get(i).eval(bindings);
+ // short circuit the case where you have one input argument whose
input type is array. So array function has
Review comment:
i have a concern with this change, best illustrated by the implication
that now an expression like this
```
array(array('x','y','z'))
```
will now produce `['x','y','z']` instead of `[['x','y','z']]` as one would
expect, or would happen if the expression were this instead:
```
array(array('x','y','z'),array('a','b','c'))
```
which will still produce `[['x','y','z'],['a','b','c']]`
Instead of hijacking this function to accommodate multi-value string
behavior, I think we should instead add a `MV_TO_ARRAY` function in SQL that
only accepts a string, and then in the native expression layer either just use
`cast(x, 'ARRAY<STRING>')` or also add a `mv_to_array` function that basically
does the same thing as cast. This way we are explicit on when we intend to
treat a multi-value column directly as an array.
I think the changes to prevent the array constructor from being mapped for
multi-value strings are fine to leave as is though, since the mapping is sort
of strange
--
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]
