You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2018/11/30 22:10:00 UTC
[jira] [Updated] (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 updated IMPALA-7914:
--------------------------------
Description:
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}
was:
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}
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org