-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-28143][SQL] Expressions without proper constructors should throw AnalysisException #24947
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
cc @cloud-fan |
|
Test build #106819 has finished for PR 24947 at commit
|
|
retest this please |
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/FunctionRegistry.scala
Show resolved
Hide resolved
|
Test build #106823 has finished for PR 24947 at commit
|
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/FunctionRegistry.scala
Outdated
Show resolved
Hide resolved
sql/core/src/test/scala/org/apache/spark/sql/SQLQuerySuite.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/FunctionRegistry.scala
Outdated
Show resolved
Hide resolved
|
Test build #106833 has finished for PR 24947 at commit
|
|
does the problem still exist when we turn on |
|
@cloud-fan spark.sql.parser.ansi.enabled=true works fine |
|
Then I think it's a parser issue(and is already fixed), we shouldn't hack |
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/FunctionRegistry.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/FunctionRegistry.scala
Outdated
Show resolved
Hide resolved
|
Test build #106856 has finished for PR 24947 at commit
|
|
Test build #106866 has finished for PR 24947 at commit
|
|
retest this please |
|
Test build #106874 has finished for PR 24947 at commit
|
| val expectedNumberOfParameters = if (validParametersCount.length == 1) { | ||
| val expectedNumberOfParameters = if (validParametersCount.isEmpty) { | ||
| constructors.headOption.map(_.getParameterCount).getOrElse(0).toString | ||
| } else if (validParametersCount.length == 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yaooqinn, can you show the error message before and after this change, and fix the PR description and title? I think this PR now targets throw a better exception for the expression that has no constructors to call.
|
@yaooqinn I think there are some last comments to address? |
|
@srowen I have updated the pr description and title as last comment required. If anything I misread, please correct me. Thanks very much. |
|
@HyukjinKwon is that OK by you? |
|
Test build #4826 has finished for PR 24947 at commit
|
| .map(_.getParameterCount).distinct.sorted | ||
| val expectedNumberOfParameters = if (validParametersCount.length == 1) { | ||
| val expectedNumberOfParameters = if (validParametersCount.isEmpty) { | ||
| constructors.headOption.map(_.getParameterCount).getOrElse(0).toString |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using headIption is hacky. We should follow the same logic what we are doing here.
| val params = Seq.fill(expressions.size)(classOf[Expression]) | ||
| val f = constructors.find(_.getParameterTypes.toSeq == params).getOrElse { | ||
| val validParametersCount = constructors | ||
| .filter(_.getParameterTypes.forall(_ == classOf[Expression])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we remove this line, what is the outcome?
In this PR, the logic is to add a special case. When unable to find a constructor whose parameters are all Expressions, we use the remaining constructors. [Note, headOption means we only choose the first one] Could you please check whether we should list all of them in the error messages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we remove this line, it works fine. I did this in the first commit of the pr, discussed with HyukjinKwon here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, It doesn't work fine.
We should only recognise the constructor with expressions because those are only able to be used in SQL. Otherwise, it shows incorrect information about possible argument combination which partially reverts #21226.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that we have function registered in but that's unable/not supposed to to call via in(...) currently. Possibly there might be more cases like this.
|
Test build #108197 has finished for PR 24947 at commit
|
|
retest this please |
|
Test build #108226 has finished for PR 24947 at commit
|
|
Seems we're blocked by #24947 (comment), shall we close this and investigate if we can remove those functions from function registry? That way will cleanly fix this issue. |
What changes were proposed in this pull request?
SQL queries like
select 1 where in (), which miss the attribute name should throwAnalysisExceptionwithInvalid number of arguments for function inas debug message rather thanjava.lang.UnsupportedOperationException: empty.init.This problem I guess is related to this pr - #21226
How was this patch tested?
Before
After