A way to specify constant/scalar arguments in UDFs

[Jefffrey]

Is your feature request related to a problem or challenge?

Some UDFs may expect a constant/scalar/literal argument, and not allow array inputs.

For example, arrow_cast:

datafusion/datafusion/functions/src/core/arrow_cast.rs

Lines 134 to 148 in f27e50c

	type_arg
	.and_then(|sv| sv.try_as_str().flatten().filter(|s| !s.is_empty()))
	.map_or_else(
	|| {
	exec_err!(
	"{} requires its second argument to be a non-empty constant string",
	self.name()
	)
	},
	|casted_type| match casted_type.parse::<DataType>() {
	Ok(data_type) => Ok(Field::new(self.name(), data_type, nullable).into()),
	Err(ArrowError::ParseError(e)) => Err(exec_datafusion_err!("{e}")),
	Err(e) => Err(arrow_datafusion_err!(e)),
	},
	)

Describe the solution you'd like

Some way to specify this at the signature level instead of needing this manual handling. This can then centralize the logic across the functions that need this.

Describe alternatives you've considered

No response

Additional context

Perhaps wire it only into the coercible signatures?

[getChan]

take

[getChan]

I think there are three possible places to model the constant/literal-argument requirement:

Design	Pros	Cons
Add is_scalar / is_literal to Coercion	Small implementation change; reuses the existing coercible-signature flow	Mixes type coercion with expression/value constraints; Coercion becomes responsible for more than type conversion
Add argument constraints to Signature	Keeps type coercion separate from value constraints; clear for functions where the same argument constraint applies to every accepted type alternative	Less suitable if different OneOf alternatives need different constraints
Add constraints to the argument definitions inside TypeSignature	Most expressive; constraints can vary per signature alternative and per argument	Larger API and migration cost; more implementation work

For the current use cases (arrow_cast, arrow_try_cast, and date_part), the literal requirement appears to be common across all accepted alternatives. For now, I will proceed with the is_scalar field on Coercion as the minimal implementation and validate the approach with tests.

If we later need alternatives with different literal requirements, the constraint could instead live with each argument in the TypeSignature alternative.

[dd-annarose]

sorry I started working on it without checking the existing issues... 😅