Fixed ambiguous SET columns in UPDATE ... FROM

[Hydrocharged]

In UPDATE ... FROM, SET columns now bind to the target table instead of erroring as ambiguous when a FROM table has the same column name.

[github-actions]

	Main	PR
Total	42090	42090
Successful	20955	20956
Failures	21135	21134
Partial Successes1	5404	5405

	Main	PR
Successful	49.7862%	49.7885%
Failures	50.2138%	50.2115%

${\color{lightgreen}Progressions (1)}$

insert_conflict

QUERY: insert into insertconflicttest values (26, 'Peach') on conflict (key) do update set fruit = excluded.fruit;

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

Commit: 163b6fc: 12 test cases ran, 12 passed ✅.

Summary

Coverage spans ordinary and multi-table data updates, conflict-based inserts and updates, array and scalar values, aliases and qualified names, returned and persisted results, and recovery after rejected input. It also checks edge cases where column names are ambiguous and where conflict conditions prevent changes, with healthy behavior across the exercised database operations.

Safe to merge — all exercised behaviors passed, including edge cases and recovery after an expected rejected operation, with no PR-attributable regressions or unresolved failures. No merge blocker is indicated by this run.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The matching target row received the source values in both aliased and table-name forms, while the unmatched row stayed unchanged.
✅	—	General	The conflicting row received the proposed scalar and array values, while a new row was inserted with its original values. A row blocked by the conflict condition stayed unchanged.
✅	—	General	The ambiguous update was rejected, and the next ordinary update on the same connection succeeded with value 42.
✅	—	Qualifier	The database updated row 1 with the source values and left row 2 unchanged.
✅	—	Qualifier	The database rejected an UPDATE that used the same unqualified column name in both the target and source tables. It returned PostgreSQL error code 42702 instead of choosing a column silently.
✅	—	Rev	The qualified UPDATE completed successfully, returned id 1 with value 7, and persisted value 7 in the target table.
✅	—	Rev	The update completed successfully and the target query returned id 1 with value 5.
✅	—	Rev	The quoted target alias worked for both the scalar value and array element update. The saved row contained value 9 and array {0,9}.
✅	—	Update	The database updated the requested row from v 0 to v 10 and changed the note from 'old' to 'new'.
✅	—	Update	The array element update completed and the row was read back with arr {0,7}.
✅	—	Upsert	The conflict update changed the existing row from v=0 to v=10 and returned id 1 with v 10.
✅	—	Upsert	The conflict update changed only the second array element, returning the existing row as {0,5}.

Tip

Reply with @itoqa to send us feedback on this test run.

[coffeegoddd]

@Hydrocharged DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.48	2.48	0.0
groupby_scan_postgres	84.47	87.56	3.66
index_join_postgres	2.39	2.39	0.0
index_join_scan_postgres	1.7	1.7	0.0
index_scan_postgres	475.79	467.3	-1.78
oltp_point_select	0.39	0.4	2.56
oltp_read_only	6.67	6.67	0.0
select_random_points	0.74	0.75	1.35
select_random_ranges	1.1	1.1	0.0
table_scan_postgres	475.79	467.3	-1.78
types_table_scan_postgres	1213.57	1191.92	-1.78

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	4.57	4.65	1.75
oltp_insert	2.3	2.3	0.0
oltp_read_write	12.98	12.75	-1.77
oltp_update_index	2.52	2.52	0.0
oltp_update_non_index	2.22	2.22	0.0
oltp_write_only	5.99	5.99	0.0
types_delete_insert_postgres	5.0	5.0	0.0