fix: ProjectionPushdown internal error on NestedLoopJoin mark joins

[lyne7-sc]

Which issue does this PR close?

• Closes ProjectionPushdown internal error on NestedLoopJoin mark joins #22901.

Rationale for this change

A query whose subquery becomes a mark join (LeftMark/RightMark) can panic during the ProjectionPushdown physical optimization with an internal assertion error.

The pushdown helper try_pushdown_through_join assumes the join output schema is the plain concatenation of its two children (left ++ right) and uses join_table_borders to split the projected columns into a left group and a right group by column index. Mark joins break this assumption: they append an extra mark boolean column that does not originate from either child, so the column-index split misroutes columns to the wrong side and the subsequent child-projection rewrite fails its name-match assertion.

What changes are included in this PR?

In HashJoinExec::try_swapping_with_projection and NestedLoopJoinExec::try_swapping_with_projection, skip the try_pushdown_through_join path for mark joins (LeftMark/RightMark) and fall through to embedding the projection into the join instead.

Are these changes tested?

Yes.

Are there any user-facing changes?

Yes, only bug fixes.

[kosiew]

@lyne7-sc
Thanks for the fix. I do not see any blocking issues, just one small cleanup suggestion.

[kosiew]

Small nit: is_mark_join is only used once here, so I think this could be a little more direct if the matches! guard were inlined where the child pushdown is skipped.

if !matches!(self.join_type(), JoinType::LeftMark | JoinType::RightMark)
    && let Some(JoinData { ... }) = try_pushdown_through_join(...)?
{
    ...
} else {
    try_embed_projection(projection, self)
}

The same cleanup looks like it would apply to NestedLoopJoinExec too.

[lyne7-sc]

Thank you, I’ve inlined the guard here.