Different SQLHandlers should go through the same planning logics for the same SELECT statement.

Given a SQL SELECT statement s, if we 1) run the SELECT statement alone, 2) put it under a CTAS statement, 3) put it under a CREATE VIEW statement, 4) put it under a EXPLAIN PLAN statement, this statement should go through the same planning logics, and expect the same behavior.

However, this is not the case today. For instance, some SQL functionalities or data types are not supported and will hit UNSUPPORTED OPERATOR error, if we run the SELECT statement alone. But if we put it under CREATE VIEW statement, it will pass and the error is delayed until we query the view.

Another example, if the query has window function, the planner will call a HepPlanner to do some additional planning work just for the window function. However, if the same SELECT statement is put under a CTAS statement, the additional planning work is skipped. This most likely will hit execution error, or return completely wrong result. This leads to issues reported in DRILL-3293 / DRILL-3294.

Lastly, the same SELECT statement might get different plan if run alone, or run under CTAS, since different planning setting might be set.

In this JIRA, we are going to refactor part of SqlHandler code in query planning component, such that the same SELECT statement will go through the same planning logic, whether it use DefaultSqlHandler, or CreateTableHandler, or CreateViewHandler, or ExplainHandler.