Handles null calls in dynamic dispatch

[RCHowell]

Description

Handles null calls in dynamic dispatch

Tests Addressed

    OVERLAY mismatched type, compileOption: LEGACY

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE null "}, compileOption: PERMISSIVE

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE null "}, compileOption: LEGACY

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE '[' "}, compileOption: PERMISSIVE

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE '[' "}, compileOption: LEGACY

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE 'S1' ESCAPE null "}, compileOption: PERMISSIVE

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE 'S1' ESCAPE null "}, compileOption: LEGACY

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null "}, compileOption: PERMISSIVE

    null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null "}, compileOption: LEGACY

• Do your changes comply with the Contributing Guidelines
  and Code Style Guidelines? [YES/NO]
  Yes

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

Conformance comparison report-Cross Engine

	Base (legacy)	eval	+/-
% Passing	92.52%	90.05%	-2.48%
✅ Passing	5383	5239	-144
❌ Failing	435	579	144
🔶 Ignored	0	0	0
Total Tests	5818	5818	0
Number passing in both: 5042

Number failing in both: 238

Number passing in legacy engine but fail in eval engine: 341

Number failing in legacy engine but pass in eval engine: 197
⁉️ CONFORMANCE REPORT REGRESSION DETECTED ⁉️
The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact.
197 test(s) were failing in legacy but now pass in eval. Before merging, confirm they are intended to pass.
The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact.

Conformance comparison report-Cross Commit-LEGACY

	Base (cc05d7f)	e52ae93	+/-
% Passing	92.51%	92.52%	0.02%
✅ Passing	5382	5383	1
❌ Failing	436	435	-1
🔶 Ignored	0	0	0
Total Tests	5818	5818	0
Number passing in both: 5382

Number failing in both: 435

Number passing in Base (cc05d7f) but now fail: 0

Number failing in Base (cc05d7f) but now pass: 1
The following test(s) were previously failing but now pass. Before merging, confirm they are intended to pass:

Click here to see

• MYSQL_SELECT_29, compileOption: LEGACY

Conformance comparison report-Cross Commit-EVAL

	Base (cc05d7f)	e52ae93	+/-
% Passing	89.91%	90.05%	0.14%
✅ Passing	5231	5239	8
❌ Failing	587	579	-8
🔶 Ignored	0	0	0
Total Tests	5818	5818	0
Number passing in both: 5231

Number failing in both: 579

Number passing in Base (cc05d7f) but now fail: 0

Number failing in Base (cc05d7f) but now pass: 8
The following test(s) were previously failing but now pass. Before merging, confirm they are intended to pass:

Click here to see

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE null "}, compileOption: PERMISSIVE

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE null "}, compileOption: LEGACY

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE '[' "}, compileOption: PERMISSIVE

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null ESCAPE '[' "}, compileOption: LEGACY

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE 'S1' ESCAPE null "}, compileOption: PERMISSIVE

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE 'S1' ESCAPE null "}, compileOption: LEGACY

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null "}, compileOption: PERMISSIVE

• null value on any of the 3 inputs returns false{likeExpr:" d.sid LIKE null "}, compileOption: LEGACY

[johnedquinn]

Is it necessary to perform these checks?

Also, we shouldn't be checking the name this way due to case-insensitive lookup. If we need these checks, then I'd consider making var name maintain a normalized function name.

[RCHowell]

Yes, as it's basic one-time input validation. Not strictly necessary if plans come from the internal partiql-planner — but that might not always be where we receive plans from.

Ack on the normalized names.