Uh oh!
There was an error while loading. Please reload this page.
[SPARK-28989][SQL] Introduce ANSI SQL Dialect - #25693
Conversation
SparkQA
commented
Sep 5, 2019
Test build #110171 has finished for PR 25693 at commit
|
e563977 to
58cc6dbCompareSparkQA
commented
Sep 5, 2019
Test build #110173 has finished for PR 25693 at commit
|
gengliangwang
commented
Sep 5, 2019
Uh oh!
There was an error while loading. Please reload this page.
mgaido91
commented
Sep 5, 2019
I am not sure about removing them... Shall we just use this config to set them, but leave the other configs for finer tuning? |
SparkQA
commented
Sep 5, 2019
Test build #110174 has finished for PR 25693 at commit
|
SparkQA
commented
Sep 5, 2019
Test build #110175 has finished for PR 25693 at commit
|
cloud-fan
commented
Sep 5, 2019
@mgaido91 in practice it's a bad idea to have tons of flags that can change query result. When debugging a Spark query that returns unexpected result, it's very annoying if you need to check a lot of flags. The legacy configs are ok as we clearly show the preference and these configs will be removed evetually, so not many people would set them. |
mgaido91
left a comment
There was a problem hiding this comment.
shall we also add a note in the migration guide?
| .createOptional | ||
| val ANSI_ENABLED = buildConf("spark.sql.ansi.enabled") | ||
| .doc("When true, tries to conform to the ANSI SQL specification. For example, Spark will " + |
There was a problem hiding this comment.
Instead of reporting as examples, shall we list clearly all the changes here?
SparkQA
commented
Sep 5, 2019
Test build #110176 has finished for PR 25693 at commit
|
maropu
left a comment
There was a problem hiding this comment.
This change looks reasonable to me.
dongjoon-hyun
commented
Sep 5, 2019
Hi, @gatorsmile , @gengliangwang , @cloud-fan . |
gengliangwang
commented
Sep 6, 2019
@dongjoon-hyun There are features specified in ANSI SQL, such as throw error on numeric value overflow. We can switch these features with the option ANSI SQL only specified high-level syntax and rules. There are "implementation-defined" behaviors, such as the result type of division of two exact number. We cant switch these detail behaviors via the option |
gengliangwang
commented
Sep 6, 2019
I will do more investigations and see if I can find a better solution for the configuration. Mark this as WIP for now. |
spark.sql.ansi.enabledspark.sql.ansi.enabledgengliangwang
commented
Sep 17, 2019
I will continue this one after the bug fix of #25804 is merged |
spark.sql.ansi.enabledspark.sql.ansi.enabled13c36a5 to
7c32feeCompareSparkQA
commented
Sep 18, 2019
Test build #110904 has finished for PR 25693 at commit
|
SparkQA
commented
Sep 18, 2019
Test build #110906 has finished for PR 25693 at commit
|
gengliangwang
commented
Sep 18, 2019
This is ready for review. |
dongjoon-hyun
left a comment
There was a problem hiding this comment.
LGTM.
cc @rxin , @gatorsmile
maropu
commented
Sep 19, 2019
Looks ok to me, too. |
spark.sql.ansi.enabledspark.sql.ansi.enabledgatorsmile
commented
Sep 19, 2019
LGTM Thanks! Merged to master. |
spark.sql.ansi.enabled
What changes were proposed in this pull request?
Currently, there are new configurations for compatibility with ANSI SQL:
spark.sql.parser.ansi.enabledspark.sql.decimalOperations.nullOnOverflowspark.sql.failOnIntegralTypeOverflowThis PR is to add new configuration
spark.sql.ansi.enabledand remove the 3 options above. When the configuration is true, Spark tries to conform to the ANSI SQL specification. It will be disabled by default.Why are the changes needed?
Make it simple and straightforward.
Does this PR introduce any user-facing change?
The new features for ANSI compatibility will be set via one configuration
spark.sql.ansi.enabled.How was this patch tested?
Existing unit tests.