Simplify planning of MERGE

[martint]

Currently, the planner inserts a projection of the following shape to assemble the merged row:

merge_row := (
    CASE
        WHEN ... THEN
            ROW(..., $not((present IS NULL)), <operation>, 0)
        WHEN ... THEN
            ROW(..., $not((present IS NULL)), <operation>, 1)
        ...
        ELSE
            ROW(<nulls>, $not((present IS NULL)), -1, -1)
    END)

This change replaces the ELSE branch to return a single null instead of a synthetic value with nulls. By reducing the size of the projection, it allows for wider tables to be used with MERGE.

Related to #15848

Release notes

(x) No release notes needed

[djsstarburst]

This looked good to me and it looks like all the CI tests pass. I wondered why the first test in TestDeleteAndInsertMergeProcessor was removed.

[dougb]

Hi, I tried this PR and it seems to help with one of the tables I was having trouble MERGING, thank you!
Will do some more testing tomorrow.

[hashhar]

Looks good, I only have questions for my own understanding.

We used to use the synthetic value as a "marker" to signal what operation to do.
Now we rely on the fact that the table scan will not produce a tuple with the value CAST(null AS row(columns..., c1 boolean, c2 tinyint, c3 integer)) ever? Why is this assumption true? Is it true because there will never be a column in the table whose type matches the row we have created?

Or do I misunderstand something?

[hashhar]

nit: static import toList

[martint]

The columns from the table scan are wrapped in a ROW(...) with some additional fields by a synthetic projection in the plan that handles the branches of the MERGE statement. The row is then consumed by the merge processor to decide if a row is being inserted or deleted. In one of the cases, we were producing a row that was meant to be ignored by the merge processor (i.e., when none of the MERGE branches matched).