[FEAT] Adds SQL function modules

[RCHowell]

This commit defines SQLFunctions and SQLModule which are responsible for registering the Daft FunctionExpr to be accessible from SQL statements. It is basic and operates on-top-of FunctionExpr .. that is, without modifying it.

• SQLFunctions – map of names (String) to functions (SQLFunction)
• SQLFunction – wrapper type over FunctionExpr to get the validate method.
• SQLModule – holds necessary logic for a FunctionExpr variant i.e. NumericExpr, Utf8Expr, etc.

Overview

/// SQLModule for FunctionExpr::Numeric
impl SQLModule for SQLModuleNumeric {
    fn register(parent: &mut SQLFunctions) {
        use FunctionExpr::Numeric as f;
        use NumericExpr::*;
        parent.add("abs", f(Abs));
        ....
    }
}

// register
let mut functions = SQLFunctions::new();
functions.register::<SQLModuleNumeric>();


// usage
let args = plan_args(args)
let func = functions.get("abs")
let expr = func.validate(args)?

Future Considerations

• Remove SQLFunctions global lazy-static singleton; rather, make it owned by (field of) the planner.
• Remove SQLFunction wrapper type in favor of extending FunctionEvaluator trait
• Add arity checks once there are variants.
• Use multi-map to support function variants.
• Extract input validation duplication from to_field and evaluate to be used by SQLPlanner as well.
• Derive a module from macros on the daft_dsl declarations

[RCHowell]

@universalmind303

The workflows fail due to missing max which was added in the initial SQLFunctions. I have only handled scalar functions with this PR, and I would like your opinion on how to proceed with aggregations.

1. Should I extend SQLModule to support aggregations?
2. Should aggregations be handled elsewhere in the planner?
3. Should I delete the single unit test for max in order to get this work in first?

I am inclined to remove the single unit test to help get this in sooner, but I am not sure the best approach for the handling of aggregations. It may not actually be much effort to add them here just like you had done for max.

Please let me know how you would prefer to proceed, thanks!

[codspeed-hq]

CodSpeed Performance Report

Merging #2725 will not alter performance

_{Comparing RCHowell:sql-fns (62c6799) with main (3cacd59)}

Summary

✅ 10 untouched benchmarks

[universalmind303]

the issue with using FunctionExpr here is that it prevents us from using our newer exprs that have been moved over to daft-functions. Eventually we plan to migrate all of the FunctionExpr impls over to the newer ScalarUDF instead.

[universalmind303]

To make this work with aggregates (max), as well as ScalarUDF's, we'll likely want to use a trait object instead

pub trait SQLFunction {/*...*/}

pub struct SQLFunctions {
    map: HashMap<String, Arc<dyn SQLFunction>>,
}

[RCHowell]

In this revision, I've only added aggregations – I've left some notes for later PRs which might extend an existing trait upon completion of the FunctionExpr -> ScalarUDF migration.

Please let me know if you wish to include ScalarUDF in this as well, or if it's better to get this PR in as-is with a follow-up PR. Thanks!

[universalmind303]

rather than a ...?

[universalmind303]

Suggested change

	let nil = Arc::new(Expr::Literal(LiteralValue::Null));
	parent.add_agg("count", Count(nil.clone(), daft_core::CountMode::Valid));
	parent.add_agg("sum", Sum(nil.clone()));
	parent.add_agg("avg", Mean(nil.clone()));
	parent.add_agg("mean", Mean(nil.clone()));
	parent.add_agg("min", Min(nil.clone()));
	parent.add_agg("max", Max(nil.clone()));
	use daft_dsl::null_lit;
	parent.add_agg("count", Count(null_lit(), daft_core::CountMode::Valid));
	parent.add_agg("sum", Sum(null_lit());
	parent.add_agg("avg", Mean(null_lit());
	parent.add_agg("mean", Mean(null_lit());
	parent.add_agg("min", Min(null_lit());
	parent.add_agg("max", Max(null_lit());