sql: fix TypeCheck for NULLIF

[rytaft]

Prior to this commit, TypeCheck for NULLIF would set the type of the
expression NULLIF(NULL, 0) to be int. However, the correct type is
actually unknown, since the type of NULL is unknown. This commit
fixes the error by using the type of the first expression as the type
of NULLIF.

Fixes #44632

Release note (bug fix): Fixed an internal error that could occur when
NULLIF was called with one null argument.

[cockroach-teamcity]

This change is 

[RaduBerinde]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @andy-kimball and @RaduBerinde)

[rytaft]

TFTR!

bors r+

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @andy-kimball)

[craig]

Build succeeded

• GitHub CI (Cockroach)

[RaduBerinde]

I realized I am actually a little confused here. NULLIF(NULL, 0) implies that NULL gets compared for equality to 0 so we can correctly imply that the type of NULL is integer.. I tried this in postgres:

radu=> SELECT pg_typeof(NULLIF(NULL, 0));
 pg_typeof 
-----------
 integer
(1 row)

[rytaft]

Hmm interesting. I'll hold off on the backports and look into this more. Thanks for checking on this!

[andy-kimball]

Good catch. My mind just jumped to the assumption that we'd type according to the first argument, without type inference. This means that the bug is with this code in scalar.go:

	case *tree.NullIfExpr:
		input := b.buildScalar(t.Expr1.(tree.TypedExpr), inScope, nil, nil, colRefs)
		cond := b.buildScalar(t.Expr2.(tree.TypedExpr), inScope, nil, nil, colRefs)
		whens := memo.ScalarListExpr{b.factory.ConstructWhen(cond, memo.NullSingleton)}
		out = b.factory.ConstructCase(input, whens, input)

The resulting expression is not typed as null:::int like the t expression is. If we had an assert like this at the end of buildScalar, it would fail:

	if out.DataType().Identical(scalar.ResolvedType()) {
		panic("mismatched data types")
	}

The fix for the issue is to use something like tree.ReType on the input argument, similar to what the *tree.BinaryExpr case does. Also, take a look at other scalar ops in that switch; there could be other similar problems with NULL values, if both these 2 cases have problems. It's also evident we could use more tests of NULL argument expressions in the optbuilder tests.

[rytaft]

Thanks for identifying the fix, @andy-kimball (and finding the issue, @RaduBerinde!).

I've made the suggested change in #45354. Also added a few more test cases for both if and nullif.