pepijnve commented on code in PR #18183:
URL: https://github.com/apache/datafusion/pull/18183#discussion_r2555206791
##########
datafusion/physical-expr/src/expressions/case.rs:
##########
@@ -1370,6 +1445,26 @@ impl PhysicalExpr for CaseExpr {
}
EvalMethod::ScalarOrScalar => self.scalar_or_scalar(batch),
EvalMethod::ExpressionOrExpression(p) => self.expr_or_expr(batch,
p),
+ EvalMethod::WithExprScalarLookupTable {
+ lookup_table,
+ fallback_for_datatype_mismatch,
+ } => {
+ // Currently, the lookup table does not support different data
types between
+ // the <expr> and the "when" values. If that is the case, use
that eval method
+ // as a fallback instead
+ if &self
+ .body
+ .expr
+ .as_ref()
+ .unwrap()
+ .data_type(batch.schema_ref())?
+ == lookup_table.when_data_type()
+ {
+ self.with_lookup_table(batch, lookup_table)
+ } else {
+ self.case_when_with_expr(batch,
fallback_for_datatype_mismatch)
+ }
Review Comment:
Isn't the logic in `try_creating_lookup_table` kind of off. It has, for
instance, code to handle `DataType::Dictionary` typed literals. Do those
actually ever occur in practice? Perhaps that block can be simplified down to
simple scalars instead? Even if you do get a `ScalarValue::Dictionary`, why not
just unwrap that to its actual value?
The selection logic of the correct BytesMapHelperWrapperTrait would then be
something you do per batch based on the incoming array instead of up front
based on the literals. You have all the code you need in the various
`array_to_iter` implementations already afaict.
--
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]
