[antiguru]

Adds DELETE FROM t ROWS (<query>), which removes the rows a query returns, with multiplicity. DELETE ... WHERE only takes per-row predicates, and WHERE (...) IN (subquery) removes every copy of a duplicated row instead of the excess count.

The statement deletes t INTERSECT ALL q, so it removes at most as many copies of a row as the table holds and cannot drive multiplicities negative. The query's columns take implicit casts only, the ones INTERSECT ALL applies, because assignment casts round and would match rows the query does not contain. Planning reuses the INTERSECT ALL lowering, and execution reuses the read-then-write path. The form is gated behind enable_delete_rows, which is off by default and on in CI. rows still parses as a table alias unless ROWS ( is followed by the start of a query.

Standard SQL has no multiset delete. PostgreSQL expresses one through physical row identity, joining numbered copies on ctid and deleting WHERE ctid IN (...), with CTEs only organizing the query. Materialize tables have no row identity, so identical copies are indistinguishable and any content predicate removes all of them or none. Giving WHERE (...) IN (q) count semantics would change the meaning of an existing standard query, hence a separate clause.

🤖 Generated with Claude Code

[def-]

QA LLM Review

1. MEDIUM -- Assignment casts let ROWS delete table rows the query does not return

src/sql/src/plan/query.rs:834

DELETE ... ROWS casts the query's columns to the table's column types in assignment context before intersecting, and assignment casts round or truncate (numeric and float to integer, numeric to a narrower scale, timestamp precision, timestamptz to date or timestamp). A query row that equals no table row can round onto one and delete it, so the statement does not delete t INTERSECT ALL q as documented, and the extra deletions are silent.

Details

CREATE TABLE t (a int);
INSERT INTO t VALUES (1);
SELECT a FROM t INTERSECT ALL SELECT 1.4;  -- 0 rows
DELETE FROM t ROWS (SELECT 1.4);           -- DELETE 1

cast_to_table_columns uses CastContext::Assignment (src/sql/src/plan/query.rs:263). In that context numeric -> int4 is CastNumericToInt32, which rounds (src/expr/src/scalar/func/impls/numeric.rs:173), and float8 -> int, numeric -> numeric(p,s), timestamptz -> date and timestamptz -> timestamp are assignment casts too (src/sql/src/plan/typeconv.rs:635, :691, :692, :1096). The VALUES special case (plan_values_insert) applies the same cast, so ROWS (VALUES (1.4)) deletes as well. A realistic case is a numeric(10,2) column where the query supplies 10.004 from an unconstrained numeric column: it deletes the stored 10.00. For INSERT the cast only decides what gets stored. Here it decides which existing rows are destroyed, while INTERSECT ALL and WHERE (...) IN (...) compare in the unified type and match nothing.

Narrowing casts that can fail have the converse effect. A query row the table cannot hold, such as 3000000000::bigint against an int column or an over-long string against varchar(3), aborts the whole statement instead of being ignored as the commit message promises.

The cast tests in delete_rows.slt only cover lossless conversions (2.25::float8 into numeric(10,2)), so they pass either way. One fix is to plan the match like plan_set_expr plans INTERSECT ALL: unify both sides to a common type, intersect, then cast the surviving rows, which are rows of t, back to the table's types. A simpler fix is to cast in implicit context, which rejects lossy conversions at plan time.

[antiguru]

Fixed in b9245bc: the query's columns now take implicit casts only, the casts INTERSECT ALL applies when unifying, so the statement deletes exactly t INTERSECT ALL q whenever it plans and rejects lossy or narrowing conversions at plan time. I didn't cast matched rows back to the table's types, because that round trip isn't exact (timestamp through timestamptz across a DST gap).

Posted by Claude Code.