opt: unnecessary columns are added to the input of update operations

[mgartner]

In some situations, exec builder is adding unnecessary columns to mutation inputs here.

To reproduce the issue (I've used print statements here for those who don't have a debugger setup):

1. Add the following lines at the top of the updateNode.processSource function in pkg/sql/update.go:

fmt.Printf("num fetch cols: %d\n", len(u.run.tu.ru.FetchCols))
fmt.Printf("num update cols: %d\n", len(u.run.tu.ru.UpdateCols))
fmt.Printf("num source vals: %d\n", len(sourceVals))
fmt.Printf("sourceVals: %v\n\n", sourceVals)

2. Run the following logic test with TESTFLAGS='-v':

# LogicTest: local

statement ok
CREATE TABLE groups (
    id INT PRIMARY KEY
);
CREATE TABLE users (
    id INT PRIMARY KEY,
    group_id INT REFERENCES groups ON UPDATE CASCADE,
    b BOOL,
    FAMILY (id, group_id, b)
);

statement ok
INSERT INTO groups VALUES (1);
INSERT INTO users VALUES (10, 1, true), (20, 1, false);
UPDATE groups SET id = 2 WHERE id = 1;

3. Notice the following lines of output:

num fetch cols: 3
num update cols: 1
num source vals: 5
sourceVals: [10 1 true 2 1]

num fetch cols: 3
num update cols: 1
num source vals: 5
sourceVals: [20 1 false 2 1]

These are printed when the cascading FK update rows are processed. There are 3 fetch cols and 1 update col, but sourceVals includes an unnecessary fifth value. AFAICT this value (1 in this case) is never used.

Jira issue: CRDB-2865

[RaduBerinde]

Below is the output from build-cascades. I think it's just the result of doing the join and we didn't bother projecting away what we don't need..

build-cascades
UPDATE groups SET id = 2 WHERE id = 1;
----
root
 ├── update groups
 │    ├── columns: <none>
 │    ├── fetch columns: id:3
 │    ├── update-mapping:
 │    │    └── id_new:5 => id:1
 │    ├── input binding: &1
 │    ├── cascades
 │    │    └── fk_group_id_ref_groups
 │    └── project
 │         ├── columns: id_new:5!null id:3!null crdb_internal_mvcc_timestamp:4
 │         ├── select
 │         │    ├── columns: id:3!null crdb_internal_mvcc_timestamp:4
 │         │    ├── scan groups
 │         │    │    └── columns: id:3!null crdb_internal_mvcc_timestamp:4
 │         │    └── filters
 │         │         └── id:3 = 1
 │         └── projections
 │              └── 2 [as=id_new:5]
 └── cascade
      └── update users
           ├── columns: <none>
           ├── fetch columns: users.id:10 group_id:11 b:12
           ├── update-mapping:
           │    └── id_new:15 => group_id:7
           ├── input binding: &2
           ├── inner-join (hash)
           │    ├── columns: users.id:10!null group_id:11!null b:12 id:14!null id_new:15!null
           │    ├── scan users
           │    │    └── columns: users.id:10!null group_id:11 b:12
           │    ├── select
           │    │    ├── columns: id:14!null id_new:15!null
           │    │    ├── with-scan &1
           │    │    │    ├── columns: id:14!null id_new:15!null
           │    │    │    └── mapping:
           │    │    │         ├──  groups.id:3 => id:14
           │    │    │         └──  id_new:5 => id_new:15
           │    │    └── filters
           │    │         └── id:14 IS DISTINCT FROM id_new:15
           │    └── filters
           │         └── group_id:11 = id:14
           └── f-k-checks
                └── f-k-checks-item: users(group_id) -> groups(id)
                     └── anti-join (hash)
                          ├── columns: id_new:16!null
                          ├── with-scan &2
                          │    ├── columns: id_new:16!null
                          │    └── mapping:
                          │         └──  id_new:15 => id_new:16
                          ├── scan groups
                          │    └── columns: groups.id:17!null
                          └── filters
                               └── id_new:16 = groups.id:17

[github-actions]

We have marked this issue as stale because it has been inactive for
18 months. If this issue is still relevant, removing the stale label
or adding a comment will keep it active. Otherwise, we'll close it in
10 days to keep the issue queue tidy. Thank you for your contribution
to CockroachDB!