Do we want to name this something else?

I think it is worth giving this a more general name, because there are other potential uses. Maybe ElementWiseAggregateOptions? (since this is aggregation, just across instead of down)

If using "Aggregate" is too confusing, maybe "Combine" or "Merge" would work too. e.g. ElementWiseCombineOptions

Since we have ScalarAggregateOptions I think ElementWiseAggregateOptions should be ok. I've updated the PR.

This is rather a lot of code being generated; it might be nice if I could figure out the right template setup to consolidate the temporal types with their respective equivalent integral type.

There's GeneratePhysicalInteger, though that doesn't include floating point. Perhaps you could add GeneratePhysicalNumeric?

I added this. Note that if we want to have CommonTimestamp() I don't think this'll fly since we'd need to scale the timestamp values to the common unit before comparison.

No, CommonTimestamp indicates that an implicit cast is necessary (which in the case of timestamps includes the scaling). It's not the responsibility of the kernel to execute that implicit cast

Ah! Ok, my mistake. I'll add some test cases for that.

Binary types aren't implemented here, though (and would need some work/restructuring to handle).

Use arr->null_count() == 0?

This will allocate a null bitmap even if all input arrays have 0 nulls.

Instead of if (first), you could move the bitmap allocation below and use if (!output->buffers[0]).

Shouldn't we ensure it's equal to 1?

Should add a column for the options class.

Why isn't this done by default in the test setup?

Uh. I don't think generating string representations for each and every test is a good idea.

It just came to my mind that it's gonna be very confusing to have "minimum" and "maximum" functions in addition to "min_max". Perhaps we can be less ambiguous, e.g. "scalar_min", "scalar_max" (or "horizontal_min" or "row_min"...).

That's a good point. I'll rename the compute function. Perhaps elementwise_min in accordance with the options struct (though that is a bit wordy)?

That's wordy indeed. Or at least element_wise_min.

How about naming them least and greatest like they do in SQL?

How is that less ambiguous?

I just changed it to element_wise_min/max.

I agree that using least and greatest would not fully resolve the ambiguity (except to users familiar with SQL) but the use of these synonyms would at least signal that these are something different from min and max. I think element_wise_min and element_wise_max are fine and do a better job of disambiguating as long as we're OK with their length.

Instead of trying to recycle buffers, we could change the kernel's flag and allow the executor to preallocate the output data buffer. Then we populate this with the anti extreme (for maximum/uint64_t we zero the buffer). Then we wouldn't need to use a bitmap to express "no values folded yet"; get_extreme({anti_extreme, v...}) == get_extreme({v...}). We'd also be able to compute the null bitmap separately in either case: !skip_nulls AND the bitmaps, skip_nulls OR the bitmaps.

In the case where scalar_count != 0, we can ExecScalar and use the result instead of an anti_extreme

This works quite well except in the case that we have a singular NaN array argument (element_wise_min([NaN])) - in which case we want to emit NaN not the antiextreme.

Ah, maybe let's just have the 'antiextreme' of a float be NaN.

The antiextremes of float are Inf, -Inf

Inf would trip up if we had something like element_wise_min([NaN, 0], [NaN, 1]) in which case we'd want to emit NaN and not Inf as the first element. Using Inf as the antiextreme means we'd emit Inf since the kernel takes any non-NaN value over any NaN.

Huh, I was expecting fmin(NaN, x) = NaN but in fact it's fmin(NaN, x) = x. Nevermind