[
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: [email protected]
For additional commands, e-mail: [email protected]
