[
https://issues.apache.org/jira/browse/SPARK-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364264#comment-14364264
]
Michael Armbrust commented on SPARK-6200:
-----------------------------------------
Thank you for working on this. I would like to support plug-able dialects, but
I'm not sure I fully agree with the implementation. In general it would be
good to post a design on the JIRA and get agreement before doing too much
implementation.
At a high level, I wonder if something much simpler would be sufficient. I
don't expect that users will spend a lot of time switching between dialects.
Probably they will configure their preferred one in spark.defaults and never
think about it again. Additionally, we will still need {{SET
spark.sql.dialect=}} as this is public API, so why not just extend that?
Basically I would propose we do the following. Add a simple interface
{{Dialect}} that takes a {{String}} and returns a {{LogicalPlan}} as you have
done. For the built in ones you just say {{SET spark.sql.dialect=sql}} or
{{SET spark.sql.dialect=hiveql}}. For external one you simply provide the
fully qualified classname. It would also be good to be clear in the interface
what the contract is for DDL. I would suggest that Spark SQL always parses its
own DDL first and only defers to the dialect when the build in DDL parser does
not handle the given string.
> Support dialect in SQL
> ----------------------
>
> Key: SPARK-6200
> URL: https://issues.apache.org/jira/browse/SPARK-6200
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Reporter: haiyang
>
> Created a new dialect manager,support dialect command and add new dialect use
> sql statement etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
