Github user cloud-fan commented on a diff in the pull request:

    https://github.com/apache/spark/pull/11658#discussion_r56274544
  
    --- Diff: 
sql/hive/src/main/scala/org/apache/spark/sql/hive/SQLBuilder.scala ---
    @@ -354,55 +381,56 @@ class SQLBuilder(logicalPlan: LogicalPlan, 
sqlContext: SQLContext) extends Loggi
             //    +- Filter ...
             //        +- Aggregate ...
             //            +- MetastoreRelation default, src, None
    -        case plan @ Project(_, Filter(_, _: Aggregate)) => 
wrapChildWithSubquery(plan)
    +        case p @ Project(_, f @ Filter(_, _: Aggregate)) => p.copy(child = 
addSubquery(f))
     
    -        case w @ Window(_, _, _, Filter(_, _: Aggregate)) => 
wrapChildWithSubquery(w)
    +        case w @ Window(_, _, _, f @ Filter(_, _: Aggregate)) => 
w.copy(child = addSubquery(f))
     
    -        case plan @ Project(_,
    -          _: SubqueryAlias
    -            | _: Filter
    -            | _: Join
    -            | _: MetastoreRelation
    -            | OneRowRelation
    -            | _: LocalLimit
    -            | _: GlobalLimit
    -            | _: Sample
    -        ) => plan
    -
    -        case plan: Project => wrapChildWithSubquery(plan)
    +        case p: Project => p.copy(child = addSubqueryIfNeeded(p.child))
     
             // We will generate "SELECT ... FROM ..." for Window operator, so 
its child operator should
             // be able to put in the FROM clause, or we wrap it with a 
subquery.
    -        case w @ Window(_, _, _,
    -          _: SubqueryAlias
    -            | _: Filter
    -            | _: Join
    -            | _: MetastoreRelation
    -            | OneRowRelation
    -            | _: LocalLimit
    -            | _: GlobalLimit
    -            | _: Sample
    -        ) => w
    -
    -        case w: Window => wrapChildWithSubquery(w)
    -      }
    +        case w: Window => w.copy(child = addSubqueryIfNeeded(w.child))
     
    -      private def wrapChildWithSubquery(plan: UnaryNode): LogicalPlan = {
    -        val newChild = SubqueryAlias(SQLBuilder.newSubqueryName, 
plan.child)
    -        plan.withNewChildren(Seq(newChild))
    +        case j: Join => j.copy(
    +          left = addSubqueryIfNeeded(j.left),
    +          right = addSubqueryIfNeeded(j.right))
           }
         }
     
    -    object UpdateQualifiers extends Rule[LogicalPlan] {
    -      override def apply(tree: LogicalPlan): LogicalPlan = tree 
transformUp {
    -        case plan =>
    -          val inputAttributes = plan.children.flatMap(_.output)
    -          plan transformExpressions {
    -            case a: AttributeReference if 
!plan.producedAttributes.contains(a) =>
    -              val qualifier = inputAttributes.find(_ semanticEquals 
a).map(_.qualifiers)
    -              a.withQualifiers(qualifier.getOrElse(Nil))
    -          }
    -      }
    +    private def addSubquery(plan: LogicalPlan): SubqueryAlias = {
    +      SubqueryAlias(SQLBuilder.newSubqueryName, plan)
    +    }
    +
    +    private def addSubqueryIfNeeded(plan: LogicalPlan): LogicalPlan = plan 
match {
    +      case _: SubqueryAlias => plan
    +      case _: Filter => plan
    +      case _: Join => plan
    +      case _: LocalLimit => plan
    +      case _: GlobalLimit => plan
    +      case _: SQLTable => plan
    +      case OneRowRelation => plan
    --- End diff --
    
    As the 
[comments](https://github.com/apache/spark/pull/11658/files#diff-9a541c718fe730b5a10f2b24041ce1f5R336)
 says, we don't need to add sub-query if this operator can be put after FROM. 
So obviously, `SubqueryAlias`, `Join`, `SQLTable`, `OneRowRelation` don't need 
extra sub-query. Currently we only support convert logical plan that is parsed 
from SQL string to SQL string, this implies, `Filter`, `Limit` will always 
appear after `Project` and they will generate SQL string like `... WHERE ... 
LIMIT ...` which can be put after FROM.
    
    Anyway this logical is just copied from original code.


---
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