left, right, and substr always return Utf8View for Utf8 input

[xudong963]

Is your feature request related to a problem or challenge?

left, right, and substr currently return Utf8View even when their first argument is Utf8 or LargeUtf8.

This makes these functions inconsistent with other string-producing functions such as lower, upper, reverse, translate, and substr_index, which preserve the first argument's string type. It also means users cannot keep Utf8 flowing through these functions even when they explicitly opt out of view types with datafusion.sql_parser.map_string_types_to_utf8view=false and datafusion.execution.parquet.schema_force_view_types=false.

This is especially surprising for systems that intentionally avoid view types at API or materialization boundaries: a query such as substr(utf8_col, 1, 3) silently produces Utf8View and then downstream code has to add explicit casts back to Utf8.

Describe the solution you'd like

Make left, right, and substr preserve the first argument's string type:

• Utf8 -> Utf8
• LargeUtf8 -> LargeUtf8
• Utf8View -> Utf8View

This matches the behavior of lower / upper and still keeps the optimized view-array path for Utf8View inputs.

Describe alternatives you've considered

The current behavior was introduced for performance because Utf8View can represent slices without copying for regular string input. Another possible design would be an explicit configuration option, but the return type of scalar functions is currently not configuration-driven, so input-driven return types are simpler and consistent with nearby string functions.

Additional context

This revisits the tradeoff from #21441 / #21442 and the similar substr optimization. The goal is not to remove Utf8View support, but to avoid forcing it when callers use Utf8 / LargeUtf8 input.

[xudong963]

cc @neilconway and @Jefffrey

[Jefffrey]

Another possible design would be an explicit configuration option, but the return type of scalar functions is currently not configuration-driven

I do wonder if we should explore this approach, as I do see and agree with both sides here (maintaining input type but also trying to optimize where possible) 🤔

Though that would mean adding more codepaths to the functions themselves (unless we do it in a smart way?)

[xudong963]

@Jefffrey Thanks! A config-driven return type is technically possible now via ScalarUDFImpl::with_updated_config.

But I still think an input-driven return type is the better default fix here. Reusing the existing map_string_types_to_utf8view or parquet schema_force_view_types options would be misleading because those control SQL type mapping / parquet schema inference, not scalar function output semantics. Adding a new option would also add another schema/planning mode and more test/code paths for these functions.

My preference would be:

• Utf8 -> Utf8
• LargeUtf8 -> LargeUtf8
• Utf8View -> Utf8View

and keep the zero-copy optimized path for Utf8View inputs.