Skip to content

Coercible signature: how to specify some inputs should have exact same type? #24136

Description

@Jefffrey

Is your feature request related to a problem or challenge?

Looking at btrim for example:

signature: Signature::one_of(
vec![
TypeSignature::Coercible(vec![
Coercion::new_exact(TypeSignatureClass::Native(logical_string())),
Coercion::new_exact(TypeSignatureClass::Native(logical_string())),
]),
TypeSignature::Coercible(vec![Coercion::new_exact(
TypeSignatureClass::Native(logical_string()),
)]),
],
Volatility::Immutable,
),

It specifies it accepts 2 string input types. However the planner doesn't coerce them to a common type, leaving it up to the UDF to handle casting to a common type for simplicity (otherwise get explosion of string types to handle):

/// Returns the longest string with leading and trailing characters removed. If the characters are not specified, spaces are removed.
/// btrim('xyxtrimyyx', 'xyz') = 'trim'
fn btrim<T: OffsetSizeTrait>(args: &[ArrayRef]) -> Result<ArrayRef> {
let use_string_view = args[0].data_type() == &DataType::Utf8View;
let args = if args.len() > 1 {
let arg1 = arrow::compute::kernels::cast::cast(&args[1], args[0].data_type())?;
vec![Arc::clone(&args[0]), arg1]
} else {
args.to_owned()
};
general_trim::<T, TrimBoth>(&args, use_string_view)
}

Describe the solution you'd like

Some way in the coercible signature API to specify when inputs should have same type. We previously could do this via:

TypeSignature::Uniform(2, vec![Utf8, Utf8View, LargeUtf8])
TypeSignature::Exact(vec![Utf8, Utf8]) // and other variants
TypeSignature::String(2)

So if we want to still try move toward coercible API, it would be good to support this somehow otherwise its very much less ergonomic for UDFs to handle this logic themselves.

Describe alternatives you've considered

No response

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions