C.f. original comment here: #123589 (comment)

For LOOKUP JOIN and other join types, we could safely assume that the attributes present in one join child are completely disjoint from the set of attributes ever present in the other child. We could rely on this fact e.g. for the correctness of the PruneColumns optimizer rule (c.f.

InlineJoin breaks with this assumption, because it specifically references attributes from the left child in the right child.

I think we should decide if we should enforce this assumption; it would much simplify assumptions needed to make to reason about optimizer rules, what happens in case of multiple Joins with the same right hand side etc. (LOOKUP JOIN specifically generates different attributes even if the very same LOOKUP JOIN command is used multiple times to avoid bugs and problems.) On the flip side, enforcing this assumption would require slightly re-modeling InlineJoin. Maybe there's also a middle ground where attributes can only be generated in one child of a join but can be referenced from both (that's currently the case, but it's harder to enforce.)

Depending on the decision, we'll need to:

• If we don't want to enforce this assumption, or not to the full extent, double check all optimizer rules for compatibility with binary plans.
• Otherwise, re-model InlineJoin and StubRelation to comply with the assumption.