release-25.2: colexec: fix projections with constant NULL values

[blathers-crl]

Backport 1/1 commits from #156962 on behalf of @mgartner.

---

This commit fixes a bug in the vectorized engine that caused internal
errors when projections operated on constant NULL values. The
proj_const_right_ops operators do not correctly handle NULL inputs. So,
we avoid these code paths when operator does not operate on NULL values
and the LHS or RHS of an operator is NULL by simply projecting NULLs.
This is similar to the change made in #128123 and addresses a TODO added
in that PR.

This code path is unlikely to hit (maybe impossible) without generic
query plans. In an optimized cusotm plan, the optimizer will fold
expressions with NULL values at optimization time, and the execution
engine will never see expressions of this form.

Fixes #152771

Release note (bug fix): A bug has been fixed that could cause internal
errors for queries using generic query plans with NULL placeholder
values.

---

Release justification: Low-risk bug fix.

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that it falls into one of the following categories (select one):

• Non-production code changes. Includes test-only changes, build system changes, etc.
• Fixes for serious issues. Defined in the policy as correctness, stability, or security issues, data corruption/loss, significant performance regressions, breaking working and widely used functionality, or an inability to detect and debug production issues.
• Other approved changes. These changes must be gated behind a disabled-by-default feature flag unless there is a strong justification not to.

Add a brief release justification to the PR description explaining your selection.

Also, confirm that the change does not break backward compatibility and complies with all aspects of the backport policy.

All backports must be reviewed by the TL and EM for the owning area.

[cockroach-teamcity]

This change is 

[yuzefovich]

This probably doesn't qualify for backport to 25.2, will defer to @michae2 on this one.

@yuzefovich reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @mgartner and @michae2)

[blathers-crl]

✅ PR #156977 is compliant with backport policy

Confidence: high
Critical bug criteria met: [Stability or security issues Bugs that can cause the DB to return incorrect results or result in suboptimal performance]
Backward compatible: true
Explanation: The pull request is compliant with the CockroachDB backport policy for several reasons:

1. Release Justification: The PR body includes a 'Release justification:' statement indicating that this is a 'Low-risk bug fix.' This statement helps justify the backport as per the backport policy exceptions for release justification.
2. Critical Bug Fix: The changes fix an issue where projections in the vectorized engine could lead to internal errors when operated on constant NULL values. Such errors pertain to the bug categories of 'Stability issues' or 'Bugs that can cause the DB to return incorrect results,' which makes this a critical bug needing immediate fixing, thereby exempting it from feature flag requirements.
3. File Changes: The files changed (pkg/sql/colexec/colbuilder/execplan.go and pkg/sql/logictest/testdata/logic_test/vectorize) are involved directly in query execution and logic test, which suggests the fix is critical for stable system operation. The tests added help validate the fix without altering the behavior of unrelated system parts.
4. Backward Compatibility: The changes are additions and modifications of logic within existing operational paths, which do not remove version gates or disrupt backward compatibility.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[mgartner]

This probably doesn't qualify for backport to 25.2, will defer to @michae2 on this one.

Ya, maybe not. There are risks on both sides.

Hitting this is much more likely in v25.2 which enabled generic query plans by default. If we do not backport, then we risk workloads hitting this internal error—and it will be hit sporadically depending on the arguments and whether or not a generic query plan is selected. That being said, one could argue that passing NULL placeholder values inside binary expressions like this is probably uncommon, so the chance of hitting the error is low.

If we backport, there is some chance that this change is incorrect or dangerous (or unlocks other incorrect or dangerous code paths). In the worst case we'd see incorrect results or nodes panic. It's difficult to quantify this risk.

[michae2]

I agree with blather's analysis. I think we can consider this a serious issue, because it becomes much more likely in 25.2 with generic query plans. Spurious query failures after upgrade to 25.2 would be an escalation to us. So I don't think we need an ENGREQ for this. And I think this qualifies for the feature flag exception because it's < 5 loc and no customer would consider it a breaking change.

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)

[yuzefovich]

(Just to be clear, I have no concerns whatsoever about the risk of this change, and if it was up to me, I'd backport this without reservations. My comment was mostly about having enough justification given the stricter backport policy. 😉 )