opt: add FoldFunctionWithNullArg normalization rule

[mgartner]

This commit adds the FoldFunctionWithNullArg normalization rule which
folds a function that does not allow Null arguments to Null when one of
the arguments is Null. See the documentation for the new rule for more
details.

Release note (performance improvement): The optimizer now folds
functions to NULL when the function does not allow NULL arguments
and one of the arguments is a NULL constant. As a result, more
efficient query plans will be produced for queries with these types of
function calls.

[cockroach-teamcity]

This change is 

[mgartner]

The first commit is from #62893.

[mgartner]

This might be proof that we can fold ANY function where NullableArgs=false and one of the args is Null:

cockroach/pkg/sql/sem/tree/eval.go

Line 4005 in f7f895c

if arg == DNull && !expr.fnProps.NullableArgs {

It looks like a function is never really evaluated in that case. So maybe I can lift the restrictions on the function being non-volatile and a normal function?

[rytaft]

To decide whether to support volatile and non-normal functions, maybe check what the TypeCheck code does for non-typed NULLs? Might also be useful to get the perspective from @yuzefovich on the execution side. But it seems to me like at least volatile functions should be safe to fold here. Not 100% sure about non-normal functions.

Reviewed 3 of 3 files at r1, 5 of 5 files at r2.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @RaduBerinde)

[RaduBerinde]

LGTM

In principle, we can have a volatile function that has some side-effect, even if it always returns NULL on NULL input. But I don't think we have any real cases like that, and as you pointed out, the existing code wouldn't evaluate it anyway:

[email protected]:26257/defaultdb> select crdb_internal.force_error('', 'foo');
ERROR: foo
[email protected]:26257/defaultdb> select crdb_internal.force_error('', NULL);
  crdb_internal.force_error
-----------------------------
  NULL
(1 row)

Let's add to the documentation for FunctionProperties.NullableArgs saying explicitly that the function won't be evaluated if an arg is NULL so if it is expected to produce side-effects in that case, the flag should be true (and that if this is changed, this optimizer rule should be adjusted).

[mgartner]

Let's add to the documentation for FunctionProperties.NullableArgs saying explicitly that the function won't be evaluated if an arg is NULL so if it is expected to produce side-effects in that case, the flag should be true (and that if this is changed, this optimizer rule should be adjusted).

Good idea. Done.

[mgartner]

@RaduBerinde mind taking a final look before I merge?

[RaduBerinde]

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

[mgartner]

TFTRs!

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)