[vshalpnjabi]

Which issue does this PR close?

• Closes UPDATE accepts more than one assignment to the same column #27096.

Rationale for this change

UPDATE t SET a = 1, a = 2 planned successfully and applied only the last assignment. The SQL standard doesn't allow the same column twice in a SET list, and PostgreSQL and DuckDB reject it. A typo like SET a = x, a = y (meant b = y) would silently update the wrong data.

What changes are included in this PR?

SqlToRel::update_to_plan now inserts SET targets into the column map one at a time and returns a planning error on a repeat:

Error during planning: multiple assignments to same column "a"

t.a and a count as the same target, since the planner already keys SET columns by the last identifier.

Are these changes tested?

Yes:

• update_rejects_duplicate_assignment in datafusion/sql/tests/sql_integration.rs (adjacent duplicates, a duplicate after another column, qualified + unqualified). It fails on main and passes with the fix.
• update.slt: the issue's reproducer, plus a normal SET a = 1, b = 2 that still updates.

Ran locally:

• cargo test -p datafusion-sql
• cargo test --profile=ci -p datafusion-sqllogictest --test sqllogictests -- update.slt
• cargo clippy -p datafusion-sql --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check

Are there any user-facing changes?

Yes. An UPDATE that assigns the same column more than once is now a planning error instead of keeping the last value. No public API changes.

One assumption to flag: the check compares the same key the planner already used (Ident.value, as written), so it doesn't add any identifier normalization of its own.

AI-assisted; I reviewed the full diff and ran the tests myself.

[vshalpnjabi]

@alamb Ready for review when you have a moment — thanks!