Extend SQL Diagnostics: Attach Source Spans to Function Argument Type Errors

[satwikmishra11]

Summary

Following the SQL Diagnostics framework introduced in v46.0.0, I'd like to extend
it to cover function argument type errors — one of the most common and confusing
error categories for end users.

Motivation

The 46.0.0 release blog explicitly noted:

"Currently, diagnostics cover unresolved table/column references, missing GROUP BY
columns, ambiguous references, wrong number of UNION columns, type mismatches, and
a few others. Future releases will extend this to more error types."

Right now, calling a function with a wrong argument type produces a generic error
with no source location:

SELECT sqrt('hello');

Describe the solution you'd like

The user gets no span, no pointer to which argument is wrong, and no hint about
what type was expected. Compare this to how a missing GROUP BY column now renders
with a precise highlight in the query text — the UX gap is significant.

Proposed Change

Extend the existing Diagnostic / DiagnosticEntry framework
(datafusion/common/src/diagnostic.rs) so that when the planner/type-coercion
layer rejects a scalar function call due to argument type mismatch, the emitted
error includes:

1. A Diagnostic that attaches a source span pointing to the offending
   argument expression in the original SQL query text.
2. A human-readable note of the form:
   "function 'sqrt' does not support argument of type Utf8 at position 1; expected a numeric type"

This matches the style and severity conventions already used in the existing
diagnostic emission sites.

Scope

Minimum viable coverage :

• Math functions called with a non-numeric argument
  e.g. SELECT sqrt('hello'), SELECT abs(true)
• String functions called with a non-string argument
  e.g. SELECT length(3.14) (where implicit coercion does not apply)
• Sqllogictest .slt test cases verifying the diagnostic text is present
  in the error output for each covered case
• No regression in existing tests

Out of scope for this PR :

• Aggregate or window function argument errors
• Errors arising from the wrong number of arguments (separate error path)

Files I Plan to Touch

File	Reason
datafusion/sql/src/planner/expr.rs	Where SQL AST exprs are resolved; span info is available here
datafusion/expr/src/type_coercion/functions.rs	Where argument type checking fires
datafusion/common/src/diagnostic.rs	Diagnostic / DiagnosticEntry types — read-only reference
datafusion/sqllogictest/test_files/	New .slt test cases

Questions Before I Start

1. Is this the right layer to attach spans? My reading is that expr.rs in
   the planner is the right place (since the AST span is still available there),
   rather than deeper in type_coercion/. Happy to be corrected.

2. Is @eliaperantoni or another committer willing to be the supervising
   maintainer for this? Per the contributor guide, I want to confirm there's
   someone interested in reviewing before investing significant time. I don't want
   to submit a PR that sits unreviewed.

3. Any prior art or in-flight PRs I should be aware of? I searched open issues
   and PRs and didn't find an active effort here, but I may have missed something.

References

• DataFusion 46.0.0 release blog — SQL Diagnostics section
• datafusion/common/src/diagnostic.rs
• Contributor guide: Discussing New Features

Happy to iterate on scope or approach based on feedback here before writing any code.

Describe alternatives you've considered

No response

Additional context

No response

[kumarUjjawal]

GROUP BY column now renders
with a precise highlight in the query text — the UX gap is significant.

>  SELECT a, b FROM (VALUES (1, 2)) t(a, b) GROUP BY a;
Error during planning: Column in SELECT must be in GROUP BY or an aggregate function: While expanding wildcard, column "t.b" must appear in the GROUP BY clause or must be part of an aggregate function, currently only "t.a" appears in the SELECT clause satisfies this requirement
>  

[kumarUjjawal]

> SELECT sqrt('hello');
Error during planning: Failed to coerce arguments to satisfy a call to 'sqrt' function: coercion from Utf8 to the signature Uniform(1, [Float64, Float32]) failed No function matches the given name and argument types 'sqrt(Utf8)'. You might need to add explicit type casts.
        Candidate functions:
        sqrt(Float64/Float32)

Both are consistent, I don't fully understand the proposal here, can you clarify with example?

[satwikmishra11]

Thanks for the question — happy to clarify!

The key difference is rendered output, not the error message text itself.

When a GROUP BY column is missing, DataFusion's diagnostics framework renders the error with a precise source span pointing to the offending column in the original query text — something like:

Error during planning: Column "b" must appear in GROUP BY
  --> SQL:1:11
   |
 1 | SELECT a, b FROM t GROUP BY a
   |           ^ column not in GROUP BY

But for a function argument type error, even though the error message is descriptive (coercion from Utf8 to Uniform(1, [Float64, Float32]) failed), you get no source location, no --> pointer, no caret under the offending argument:

SELECT sqrt('hello');
-- No span, no pointer to 'hello', no column/line reference

The proposal is to make the rendering consistent — so the output would look like:

Error during planning: function 'sqrt' does not support argument of type Utf8 at position 1
  --> SQL:1:13
   |
 1 | SELECT sqrt('hello')
   |             ^^^^^^^ expected a numeric type

The existing Diagnostic / DiagnosticEntry framework already supports this rendering — it just hasn't been wired up for the type-coercion path yet. That's the gap I'm proposing to close.

Does that clarify the intent? Happy to refine the scope further based on your feedback before writing any code.

[kumarUjjawal]

The caret mockup you are proposing isn't produced by any code path today, the diagnostics module is pure data structure, it doesn't have any renderer, what you are proposing requires more discussion if this is something we want to have in DF so I would wait for others to express their views on this.

[kumarUjjawal]

The 46.0.0 release blog explicitly noted:

It would be also a good step to explore the 53.1.0 release for more up to date information.