`UPDATE ... SET` evaluates assignments sequentially (MySQL semantics) instead of from the pre-update row

[johannesdb]

Version: reproduced on dolthub/doltgresql:1.1.0 and 1.0.0 (clean Docker container, empty database; latest run 2026-08-15)
Class: silently wrong results — no error is raised

Repro

CREATE TABLE t_seq (a int, b int);
INSERT INTO t_seq VALUES (1, 0);
UPDATE t_seq SET a = 2, b = CASE WHEN a = 1 THEN 100 ELSE -1 END;
SELECT a, b FROM t_seq;

Actual (DoltgreSQL 1.1.0)

 a | b
---+----
 2 | -1     -- the CASE saw the NEW value of a (=2)

Expected (PostgreSQL 15, same probe)

 a |  b
---+-----
 2 | 100    -- per the SQL standard, every assignment reads the pre-update row

Impact

Any multi-column UPDATE where a later assignment references an earlier target column
computes different values than Postgres, silently. Typical real-world shape:
SET status = 'active', archived_at = CASE WHEN status = 'archived' THEN NULL ELSE archived_at END
— the branch can never fire on DoltgreSQL because status has already been overwritten.

---

Part of a clean-room deviation battery (fresh official Docker container + empty
database per probe, postgres:15 control running identical probes). Filing the
findings together so they can be triaged/batched as a set — index in a comment on
#2600. Happy to re-test any of them against a nightly/branch build.