Skip to content

Deprecate AggregateUDFImpl::is_nullable in favour of return_field #18882

@Jefffrey

Description

@Jefffrey

Is your feature request related to a problem or challenge?

Deprecate is_nullable as the same information is already encoded by the field from return_field

/// What type will be returned by this function, given the arguments?
///
/// By default, this function calls [`Self::return_type`] with the
/// types of each argument.
///
/// # Notes
///
/// Most UDFs should implement [`Self::return_type`] and not this
/// function as the output type for most functions only depends on the types
/// of their inputs (e.g. `sum(f64)` is always `f64`).
///
/// This function can be used for more advanced cases such as:
///
/// 1. specifying nullability
/// 2. return types based on the **values** of the arguments (rather than
/// their **types**.
/// 3. return types based on metadata within the fields of the inputs
fn return_field(&self, arg_fields: &[FieldRef]) -> Result<FieldRef> {
udaf_default_return_field(self, arg_fields)
}
/// Whether the aggregate function is nullable.
///
/// Nullable means that the function could return `null` for any inputs.
/// For example, aggregate functions like `COUNT` always return a non null value
/// but others like `MIN` will return `NULL` if there is nullable input.
/// Note that if the function is declared as *not* nullable, make sure the [`AggregateUDFImpl::default_value`] is `non-null`
fn is_nullable(&self) -> bool {
true
}

Describe the solution you'd like

Similar to how we did for scalar UDFs: #17074

Describe alternatives you've considered

No response

Additional context

No response

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions