Repository navigation
Improve error message for wrong argument type in operators #11250
Description
Is your feature request related to a problem or challenge?
When input arguments of unsupported type, scalar functions will return user-friendly error message:
> select abs(1,2,3);
Error during planning: Error during planning: The function expected 1 arguments but received 3 No function matches the given name and argument types 'abs(Int64, Int64, Int64)'. You might need to add explicit type casts.
Candidate functions:
abs(Any)
> select round(3.14, 2.5);
Error during planning: Error during planning: Coercion from [Float64, Float64] to the signature OneOf([Exact([Float64, Int64]), Exact([Float32, Int64]), Exact([Float64]), Exact([Float32])]) failed. No function matches the given name and argument types 'round(Float64, Float64)'. You might need to add explicit type casts.
Candidate functions:
round(Float64, Int64)
round(Float32, Int64)
round(Float64)
round(Float32)
But operators don't support it: but operators' behaviour is similar to scalar function, they both take several input argument, and return some value, maybe it's possible to also support better error message for operators
> select NOT 1.5;
type_coercion
caused by
Error during planning: Cannot infer common argument type for comparison operation Float64 IS DISTINCT FROM Boolean
> select 2.0 << 3.5;
Internal error: Data type Float64 not supported for binary operation 'bitwise_shift_left' on dyn arrays.
This was likely caused by a bug in DataFusion's code and we would welcome that you file an bug report in our issue tracker
DuckDB seems to (partly..) unify their implementation, and the error message is very informative
duckdb> select 2.0 << 3.5;
Binder Error: No function matches the given name and argument types '<<(DECIMAL(2,1), DECIMAL(2,1))'. You might need to add explicit type casts.
Candidate functions:
<<(TINYINT, TINYINT) -> TINYINT
<<(SMALLINT, SMALLINT) -> SMALLINT
<<(INTEGER, INTEGER) -> INTEGER
<<(BIGINT, BIGINT) -> BIGINT
<<(HUGEINT, HUGEINT) -> HUGEINT
<<(UTINYINT, UTINYINT) -> UTINYINT
<<(USMALLINT, USMALLINT) -> USMALLINT
<<(UINTEGER, UINTEGER) -> UINTEGER
<<(UBIGINT, UBIGINT) -> UBIGINT
<<(UHUGEINT, UHUGEINT) -> UHUGEINT
<<(BIT, INTEGER) -> BIT
LINE 1: select 2.0 << 3.5;
A reference implementation for functions' error message: #6396
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response
Reacted by Andrew Lamb and Edward Jones
Activity
Lordworms commentedon Jul 6, 2024
take
Acfboy commentedon Jan 18, 2026
Hi, @alamb , I'm interested in working on this.
I noticed #13664 has introduced the Diagnostic framework. It seems the goal now is not only updating the
Planerror string but also providing friendly operator candidate signatures within theDiagnosticstructure (in thehelpornotesfields), Is this the right direction to proceed?alamb commentedon Jan 18, 2026
If you can figure out how to use the Diagnostic framework to add a more helpful message that sounds great to me
I believe the Diagnostic framework is somewhat incomplete, so if you can't make that work I think it is ok
Acfboy commentedon Jan 18, 2026
Thanks! I'll try.
Acfboy commentedon Jan 18, 2026
take
Acfboy commentedon Jan 26, 2026
@alamb Hi, I noticed that operator error handling doesn't share the same framework as scalar functions. The scattered type inference logic makes operator error messages less user-friendly compared to functions. Is this an intended trade-off?
Would it be possible to consider gradually refactoring this part? For example, we could start by defining
TypeSignaturefor operators only for leverage the existing function-based error reporting now. And transition operator handling to a fully function-based approach in the future.alamb commentedon Jan 26, 2026
I think that would be a good idea -- the key thing to make this happen is find a maintainer that is willing to work with you on it, as well as breaking up the work into smaller chunks that are easier to review and explain
Acfboy commentedon Feb 9, 2026
@2010YOUY01
In the example you provided, I found that there seems to be a minor oversight that caused this error — which should have been returned at the logical plan stage — to not report until execution. I have attempt to fix it with one line in #20241 . XD