eliaperantoni opened a new issue, #14429:
URL: https://github.com/apache/datafusion/issues/14429

   ### Is your feature request related to a problem or challenge?
   
   In #13664 we introduced the `Diagnostic` type and 
`DataFusionError::Diagnostic`. They allow enriching errors with messages meant 
for consumption by end users of an application built on top of DataFusion, by 
providing rich information and context that directly references locations in 
the SQL query. They enable features like:
   
   
![](https://github.com/user-attachments/assets/32efeb4f-aad9-41c9-a1e3-600a00d525c3)
   
   See `datafusion/sql/tests/cases/diagnostic` for examples on how to extract 
and use diagnostics:
   
   
https://github.com/apache/datafusion/blob/d5428b21d6486e5b7db525d314ee9119a512c397/datafusion/sql/tests/cases/diagnostic.rs#L132-L140
   
   In that PR, we only implemented diagnostics for:
   
   - Unresolved table references
   - Unresolved column references (qualified and non)
   - Non-aggregate expressions missing from `GROUP BY` clause
   - Ambiguous column references
   - Wrong number of columns in set expression (e.g. `UNION`)
   - Incompatible types in binary expressions
   
   This issue is about using `Diagnostic` in more places, and adding related 
tests to `datafusion/sql/tests/cases/diagnostic`. We think we should at least 
implement the following, but suggestions are welcome and encouraged:
   
   TODO
   
   ### Describe the solution you'd like
   
   The implementation should follow the steps of #13664, by calling 
`DataFusionError.with_diagnostic` to attach a `Diagnostic` to an error that is 
currently being returned. Tests should be added to 
`datafusion/sql/tests/cases/diagnostic` for each newly supported scenario.
   
   For some of these items, it might be necessary to enrich the logical types 
with the `Span` information coming from the parser. This should be done using 
the `datafusion::common::Spans` type (note the "s"), introduced in #13664 to 
add span information to `datafusion::common::Column`.
   
   It is desirable that the implementation is as little invasive as possible, 
in that it shouldn't require changing tons of function calls and types, unless 
absolutely necessary. The public facing API shouldn't change. The `Diagnostic` 
should be attached as soon as possible to the creation of the wrapped 
`DataFusionError` (i.e. deep in the call stack) and every error should ideally 
have just one `Diagnostic`.
   
   ### Describe alternatives you've considered
   
   _No response_
   
   ### Additional context
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to