pepijnve commented on code in PR #18183:
URL: https://github.com/apache/datafusion/pull/18183#discussion_r2534758182
##########
datafusion/physical-expr/src/expressions/case.rs:
##########
@@ -1269,6 +1312,28 @@ impl CaseExpr {
self.body.expr_or_expr(batch, when_value)
}
}
+
+ fn with_lookup_table(
+ &self,
+ batch: &RecordBatch,
+ lookup_table: &LiteralLookupTable,
+ ) -> Result<ColumnarValue> {
+ let expr = self.body.expr.as_ref().unwrap();
+ let evaluated_expression = expr.evaluate(batch)?;
+
+ let is_scalar = matches!(evaluated_expression,
ColumnarValue::Scalar(_));
+ let evaluated_expression = evaluated_expression.to_array(1)?;
+
+ let output = lookup_table.map_input_to_output(&evaluated_expression)?;
Review Comment:
I don't want to make you keep on renaming this thing since this is going to
look like bike shedding. Just wondering why you want to keep some reference to
'input' and or 'output' in this name.
I'm looking at the LookupTable concept as a fairly generic 'associative
array'-like data structure where you're looking up values that correspond to
keys. I think the public interface can reflect that.
Wouldn't just `map` or `lookup` suffice? Anyway, this is just my opinion.
Might be useful to get a third opinion.
--
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]
