tree: handle null in suboperator expressions

[rafiss]

Before this change, a null right operand in a suboperator would cause an
unhandled error. We were receiving stack trace reports from the wild.
Add a test and fix it.

fixes #37547
Release note (bug fix): a null right operand now causes the suboperator
expression to return null

[cockroach-teamcity]

This change is 

[jordanlewis]

This - nice! Thinking again about it, I think you could solve the problem and also clean up the previous code a tiny bit at the same time with a small change. I left an inline suggestion.

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @asubiotto, @jordanlewis, and @rafiss)

---

pkg/sql/sem/tree/eval.go, line 3686 at r1 (raw file):

	_, newLeft, newRight, _, not := foldComparisonExpr(op, left, right)
	if !expr.fn.NullableArgs && (newLeft == DNull || newRight == DNull) {

I just realized that this code should also apply to the case with suboperators, so I think we could pull this check up above the suboperator check and avoid the new special case.

This should be valid because NULL = ANY (...) is always NULL, and x = ANY NULL is always NULL as well.

(and the detail about running this on newLeft and newRight isn't important - if you click into foldComparisonExpr, that might just reverse the order of left and right - but since we're checking if either of them for NULL-ness, we can just as well run the check before folding as after.)

---

pkg/sql/sem/tree/testdata/eval/any_some_all, line 74 at r1 (raw file):

eval
1 = ANY(NULL::int[])

small style thing: For test cases like this one, (e.g. it might not be super obvious why you need the extra cast), we typically add a comment above the test case that says that it's a regression test for an issue. So you'd say something approximately like "# Regression test for #issuenum - ensure that null RHS of comparions with suboperators are correctly handled."

[rafiss]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @asubiotto and @jordanlewis)

---

pkg/sql/sem/tree/eval.go, line 3686 at r1 (raw file):

Previously, jordanlewis (Jordan Lewis) wrote…

I just realized that this code should also apply to the case with suboperators, so I think we could pull this check up above the suboperator check and avoid the new special case.

This should be valid because NULL = ANY (...) is always NULL, and x = ANY NULL is always NULL as well.

(and the detail about running this on newLeft and newRight isn't important - if you click into foldComparisonExpr, that might just reverse the order of left and right - but since we're checking if either of them for NULL-ness, we can just as well run the check before folding as after.)

Done.

---

pkg/sql/sem/tree/testdata/eval/any_some_all, line 74 at r1 (raw file):

Previously, jordanlewis (Jordan Lewis) wrote…

small style thing: For test cases like this one, (e.g. it might not be super obvious why you need the extra cast), we typically add a comment above the test case that says that it's a regression test for an issue. So you'd say something approximately like "# Regression test for #issuenum - ensure that null RHS of comparions with suboperators are correctly handled."

Done.

[jordanlewis]

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

[asubiotto]

Reviewed 2 of 2 files at r2.
Reviewable status: complete! 1 of 0 LGTMs obtained

[asubiotto]

Looks like CI is failing. TeamCity is pretty confusing so let me know if you want a hand in figuring out what's wrong.

[rafiss]

turns out the earlier suggestion to move the check earlier in the code breaks other behavior -- a null LHS in suboperators has different behavior. i went back to the original version and added more tests.

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

[rafiss]

bors r+

[craig]

Build succeeded

• GitHub CI (Cockroach)

[jordanlewis]

Woo!

Since this is an isolated bugfix for a correctness issue that people have been seeing in the wild, you should also backport it to the 19.1 release branch so that it will be available in the next 19.1 patch release. There are instructions for this on the wiki.