Github user hvanhovell commented on a diff in the pull request:
    --- Diff: 
    @@ -1120,47 +1173,54 @@ class Analyzer(
               } else {
    -        case w : Window =>
    -          failOnOuterReference(w)
    -          failOnNonEqualCorrelatedPredicate(foundNonEqualCorrelatedPred, w)
    -          w
    -        case j @ Join(left, _, RightOuter, _) =>
    -          failOnOuterReference(j)
    -          failOnOuterReferenceInSubTree(left, "a RIGHT OUTER JOIN")
    -          j
    -        // SPARK-18578: Do not allow any correlated predicate
    -        // in a Full (Outer) Join operator and its descendants
    -        case j @ Join(_, _, FullOuter, _) =>
    -          failOnOuterReferenceInSubTree(j, "a FULL OUTER JOIN")
    -          j
    -        case j @ Join(_, right, jt, _) if !jt.isInstanceOf[InnerLike] =>
    -          failOnOuterReference(j)
    -          failOnOuterReferenceInSubTree(right, "a LEFT (OUTER) JOIN")
    +        // Join can host correlated expressions.
    +        case j @ Join(left, right, joinType, _) =>
    +          joinType match {
    +            // Inner join, like Filter, can be anywhere.
    +            // LeftSemi is a special case of Inner join which returns
    +            // only the first matched row to the right table.
    +            case _: InnerLike | LeftSemi =>
    --- End diff --
    It makes sense to extract predicates from the right hand side of a 
`LeftSemi` join. My problem with this is far more practical. `Join` with a 
`LeftSemi` join type does not output any right hand side attributes (see:,
 the plan **breaks** are as soon as you extract a correlated predicate from the 
right hand side of the join and try to rewrite the tree using that predicate. 
That is all.
    It would - fortunately - be quite simple to support this. Just rewrite 
every LeftSemi join with underlying predicates into an Inner join. I am not 
entirely sure if we should support this, technically the query is incorrect. 
Lets defer this to a follow-up PR.
    The example you give is different. I do think we should support that. 
Please note that the example you give will not have any left semi joins during 
analysis, the left semi joins are introduced during optimization; this makes it 
relatively straight forward to detect such a nested case.

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 or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to