gstvg commented on code in PR #18921: URL: https://github.com/apache/datafusion/pull/18921#discussion_r2976056024
########## datafusion/physical-expr/src/expressions/lambda.rs: ########## @@ -0,0 +1,161 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +//! Physical lambda expression: [`LambdaExpr`] + +use std::any::Any; +use std::hash::Hash; +use std::sync::Arc; + +use crate::physical_expr::PhysicalExpr; +use arrow::{ + datatypes::{DataType, Schema}, + record_batch::RecordBatch, +}; +use datafusion_common::plan_err; +use datafusion_common::{HashSet, Result, internal_err}; +use datafusion_expr::ColumnarValue; + +/// Represents a lambda with the given parameters names and body +#[derive(Debug, Eq, Clone)] +pub struct LambdaExpr { + params: Vec<String>, + body: Arc<dyn PhysicalExpr>, +} Review Comment: `LambdaArgument::evaluate` receives closures instead of eager evaluated arguments as a batch and it allows skiping the evaluation of unnecessary parameters. I also like that it encapsulates the internal lambda implementation allowing for less breaking changes in the future (I changed it a few times and I wouldn't be surprised if it must be changed again) When we add capture support, `LambdaArgument` will receive a `captures: Option<RecordBatch>` field, which will differentiate it even more from `LambdaExpr` `LambdaArgurment.params` being `FieldRef`' are used to construct the evaluation batch with precise nullability, otherwise we could only use the param datatype and set nullable to always false. Making `LambdaExpr.params` `FieldRef` instead of strings would complicate `expr_api` users as they would need to provide the Field instead of only the name And since `LambdaExpr` should only exist as a lambda function argument, where it's specially handled, I think it's good to error with a clear message if it ends up outside a lambda function , instead of likely failing with a missing field or mismatched types error, or worse, not failing at all. -- 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]
