You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2019/02/23 22:10:00 UTC

[jira] [Resolved] (IMPALA-7914) Introduce AST base class/interface for statement-like nodes

     [ https://issues.apache.org/jira/browse/IMPALA-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Rogers resolved IMPALA-7914.
---------------------------------
    Resolution: Fixed

> Introduce AST base class/interface for statement-like nodes
> -----------------------------------------------------------
>
>                 Key: IMPALA-7914
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7914
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Frontend
>    Affects Versions: Impala 3.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>            Priority: Minor
>
> The front-end is based on an abstract syntax tree (AST). The parser creates the AST, the analyzer decorates it with semantic information, and the planner creates a plan for it.
> At present, the class hierarchy looks like this:
> {noformat}
> ParseNode
> |-- Expr
> |   |-- <all expression nodes>
> |-- FromClause
> |-- <other statment fragments>
> |-- StatementBase
> |   |-- SelectStmt
> |   |-- <other statements>
> {noformat}
> This is a nuisance because the only common base class for all statement-like nodes is the {{ParseNode}}, which is also the common base class or expressions. However, expressions and statement-like nodes behave differently during analysis, SQL generation, and so on.
> We propose to refactor the tree to introduce a new {{StmtNode}} interface or class that defines the statement-like semantics, leaving {{Expr}} to define the expression-like semantics. The methods then move out of {{ParseNode}}.
> This change all allow revising the analysis step as follows:
> * Analysis of statement-like nodes is done "in place"
> * Analysis of expression nodes may result in replacing one node with a rewritten version
> Similarly, when generating SQL:
> * Statements provide the option of generating before- or after-rewrite SQL.
> * Expressions can only generate SQL for what they are; they have no concept of before- or after- rewrites.
> Specifically:
> {noformat}
> ParseNode
> |-- Expr
> |   |-- <all expression nodes>
> |-- StmtNode
> |   |-- FromClause
> |   |-- <other statment fragments>
> |   |-- StatementBase
> |   |   |-- SelectStmt
> |   |   |-- <other statements>
> {noformat}
> It may be useful to introduce a {{ClauseNode}}, but we'll see if that is actually helpful as we do the refactoring:
> {noformat}
> |-- StmtNode
> |   |-- ClauseNode
> |   |   |-- FromClause
> |   |   |-- <other statment fragments>
> |   |-- StatementBase
> |   |   |-- SelectStmt
> |   |   |-- <other statements>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)