Skip to content

Conversation

@EmilyMatt
Copy link
Contributor

Which issue does this PR close?

Rationale for this change

Reduce code duplication.

What changes are included in this PR?

A util function replacing many calls which are using the same code.

Are these changes tested?

No logic should change whatsoever, so each area which now uses this code should have it's own tests and benchmarks unmodified.

Are there any user-facing changes?

Yes, there is now a new pub function.
No other changes to API.

@github-actions github-actions bot added physical-expr Changes to the physical-expr crates physical-plan Changes to the physical-plan crate labels Nov 2, 2025
Comment on lines +103 to +113
#[inline]
pub fn evaluate_expressions_to_arrays(
exprs: &[Arc<dyn PhysicalExpr>],
batch: &RecordBatch,
) -> Result<Vec<ArrayRef>> {
let num_rows = batch.num_rows();
exprs
.iter()
.map(|e| e.evaluate(batch).and_then(|col| col.into_array(num_rows)))
.collect::<Result<Vec<ArrayRef>>>()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we handle the footgun of This means that this should not be called on expressions that may return // arrays of different lengths by matching the ColumnarValue and blowing up Scalars, passing through arrays of the same length but erroring if the result is an array of a different length?

Also since this is going to be used pretty widely maybe a docstring example, etc. would help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

physical-expr Changes to the physical-expr crates physical-plan Changes to the physical-plan crate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create unified evaluate_many util function

2 participants