Github user chenghao-intel commented on a diff in the pull request:

    https://github.com/apache/spark/pull/4015#discussion_r22911617
  
    --- Diff: sql/core/src/main/scala/org/apache/spark/sql/SQLContext.scala ---
    @@ -40,6 +41,104 @@ import 
org.apache.spark.sql.sources.{DataSourceStrategy, BaseRelation, DDLParser
     
     /**
      * :: AlphaComponent ::
    + * The entry point for parsing the SQL text to logical plan, we call this 
SQL Dialect.
    + * Currently we support the default dialect named "sql", associated with 
the class
    + * [[DefaultSQLDialect]]
    + *
    + * And we can also provide custom SQL Dialect, register it before using.
    + * For example, assume we need to provide a Hive Dialect for HiveContext, 
we can
    + * register the Dialect during the HiveContext creation
    + * {{{
    + *   class HiveContext extends SQLContext {
    + *   ...
    + *   SQLDialectFactory.registerSQLDialect("hiveql", classOf[HiveQLDialect])
    + *   ...
    + *   }
    + * }}}
    + *
    + * And in Spark SQL CLI:
    + * {{{
    + *   -- switch to "hiveql" dialect
    + *   spark-sql>SET spark.sql.dialect=hiveql;
    + *   spark-sql>SELECT * FROM src LIMIT 1;
    + *   -- switch to "sql" dialect
    + *   spark-sql>SET spark.sql.dialect=sql;
    + *   spark-sql>SELECT * FROM src LIMIT 1;
    + * }}}
    + */
    +@AlphaComponent
    +abstract class SQLDialect {
    +  /**
    +   * We assume the DDLParser has higher priority than any of the other SQL 
Parsers,
    --- End diff --
    
    Well, even if we moved the extended parser first, I don't think we want to 
skip the `DDLParser`, right? in the meantime, we have to consider the parsing 
`fallback` (once fail, we have to resort to the `DDLParser`) for EVERY extended 
parser, then, why NOT just do the `fallback` in `DDLParser` by moving it ahead 
of time? That's exactly the currently implementation!
    
    And I don't think the issues @scwf described is the motive we need to 
update the code here, probably a better solution is we define a unified 
`DescribeCommand` logical node, and it can be casted into different execution 
within the context (`HiveContext` / `SQLContext`).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

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

Reply via email to