NVL Function Incorrectly changes nullability field of its operands

We rewrite the NVL function in org/apache/calcite/sql2rel/StandardConvertletTable.java:303  , during the rewrite we currently override the operands' nullability to be NOT NULL which is not needed. This causes issues if that operand is pushdown , since the input of that operand need not be not nullable whereas we forced that operand to be Not nullable.

We rewrite the nvl function  [ NVL(op1, op2)  to CASE ( IS NOT NULL (op1), op1, op2) ]

Previously we were wrongly setting final op1, op2 nullability to NOT NULL

For Example for the query

select nvl("name", 'undefined') FROM "hr"."emps" 

Using the test framework, (Column "name" is nullable)

The generated plan before this change is:

EnumerableCalc(expr#0..4=[{inputs}], expr#5=[IS NOT NULL($t2)], expr#6=[CAST($t2):VARCHAR NOT NULL], expr#7=['undefined':VARCHAR], expr#8=[CASE($t5, $t6, $t7)], EXPR$0=[$t8])
 EnumerableTableScan(table=[[hr, emps]])

After this change:

EnumerableCalc(expr#0..4=[{inputs}], expr#5=[IS NOT NULL($t2)], expr#6=[CAST($t2):VARCHAR], expr#7= ['undefined':VARCHAR], expr#8=[CASE($t5, $t6, $t7)], EXPR$0=[$t8])
 EnumerableTableScan(table=[[hr, emps]])
 

If we look at expr#8 , its the CASE described earlier and expr#6 is the "name" column.

As described with this change we can assert that the nullability is preserved as nullable as required ( expr#6 is set to Nullable)