Workflow [BackportPR], commit [7046a86]

Summary: ✅

The only red was the PR's own test 04330_join_disjunctions_pushdown_using_type_mismatch, failing in both "distributed plan" stateless configs. The final --- analyzer no crash --- query returned an UNKNOWN_IDENTIFIER exception instead of the expected 1.

Root cause is version-specific, not a gap in the backported fix. Both source fixes (filterPushDown.cpp require_stable_types and IdentifierResolver.cpp SCOPE_EXIT) are cherry-picked faithfully. The regression query phrases its statically-dead branch (referencing the unknown identifiers t04330.x / r.s) with multiIf. On master that dead branch is folded away at analysis time by the multiIf constant-branch special case in resolveFunction.cpp (is_special_function_multi_if), so the unknown identifiers are never resolved and the query succeeds. That multiIf folding is not present in 26.5 — it was added by a separate, unrelated change (master d6cf77a8856), out of scope for this bug-fix backport — so 26.5 resolves the dead branch and throws. (The master test also carries SET explain_query_plan_default = 'legacy', but that setting does not exist in 26.5 and is irrelevant: the failure is identifier resolution, reproducible without EXPLAIN.)

Fix: express the dead branch with if instead of multiIf (a single-condition multiIf is equivalent to if). The if constant-branch special case (is_special_function_if) is present in 26.5 and swallows the dead branch identically, exercising the very same scope.join_using_columns dangling-pointer crash path that the IdentifierResolver SCOPE_EXIT fix guards.

Verified on the 26.5 amd_asan_ubsan / arm_release CI build (26.5.5.6) that the test matches the reference (including the final 1) under serialize_query_plan=1 (distributed plan), serialize_query_plan=0, and optimize_multiif_to_if=1; the original multiIf form fails. The same arm master build runs the inner query without error, confirming the version-behaviour difference.

I also merged origin/26.5 (clean, no conflicts) since the branch was a couple of days behind and red.

Correction / final approach: I superseded the multiIf -> if rewrite from my previous comment with a commit that drops the --- analyzer no crash --- query, matching the 26.4 sibling backport #108902 (commit 06d2b2b277c).

After verifying against an unpatched base-26.5 binary, the if-based variant does not reproduce the analyzer crash either: the dangling-pointer scenario in scope.join_using_columns is only reachable when the dead branch is a multiIf whose constant folding is swallowed at analysis time (is_special_function_multi_if), and that folding is not present in 26.5. So an if query would just pass regardless of the fix rather than guard it.

The query is therefore omitted with an explanatory note (final test files now identical to the 26.4 sibling apart from the 26.4/26.5 wording), the IdentifierResolver.cpp change is kept for parity with master, and the primary fix (Unexpected return type from equals disjunction push-down logical error) remains fully exercised by the first part of the test. Verified the test matches the reference on the 26.5 arm_release CI build under serialize_query_plan=1 and =0.