feat(query): support update statements

CHANGELOG.md

@@ -9,6 +9,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- feat(query): support update statements
 - feat(query): support delete statements with where clause
 - chore(loads): document table write locking and retry behavior
 - feat(jobs): add ivf_rebalance_sweep job type

docs/QueryApi.md

@@ -18,7 +18,7 @@ Set `async: true` to execute asynchronously — returns a query run ID for polli
 
 To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.
 
-The endpoint also runs write statements: `INSERT INTO … VALUES … / SELECT …` (append only), `DELETE FROM … [WHERE …]`, `CREATE TABLE`, `CREATE TABLE … AS SELECT …` and `DROP TABLE`. A write runs once, inline, and answers with a one-row result holding a single `rows_affected` column. Writes need an API key holding both the `read` and `write` permissions, may only target the database's own `default` catalog (attached catalogs stay read-only), and are never run from a saved query. A `DELETE` reports the number of rows its `WHERE` matched and deleted; `DELETE … LIMIT`, `USING` and `RETURNING` are refused. `UPDATE` is not supported yet; use the load endpoint's keyed `update` mode. Every other mutation (`ALTER`, views, `COPY`, transactions, `EXPLAIN` of a write) is refused.
+The endpoint also runs write statements: `INSERT INTO … VALUES … / SELECT …` (append only), `UPDATE … SET … [WHERE …]`, `DELETE FROM … [WHERE …]`, `CREATE TABLE`, `CREATE TABLE … AS SELECT …` and `DROP TABLE`. A write runs once, inline, and answers with a one-row result holding a single `rows_affected` column. Writes need an API key holding both the `read` and `write` permissions, may only target the database's own `default` catalog (attached catalogs stay read-only), and are never run from a saved query. A `DELETE` reports the number of rows its `WHERE` matched and deleted; `DELETE … LIMIT`, `USING` and `RETURNING` are refused. An `UPDATE` reports the number of rows its `WHERE` matched. Each `SET` value is computed from the row as it was before the statement, so `SET a = b, b = a` swaps two values. An `UPDATE` cannot use a table alias, `FROM`, `RETURNING`, `LIMIT` or `ORDER BY`, cannot set one column twice, and cannot set a column that a vector index generates; that column is computed again from its source text. On a table that declares `constant_per_key`, an `UPDATE` cannot set a key column or a `constant_per_key` column. Every other mutation (`ALTER`, views, `COPY`, transactions, `EXPLAIN` of a write) is refused.
 
 ### Example