Summary

Fixes three reported silent-correctness bugs (#22, #23, #24) and expands coverage to the full class of failures they represent. The core change is wiring the existing nodedb_query::expr::SqlExpr evaluator into every place the planner previously gave up on non-trivial expressions.

What was broken

• Scalar functions in WHERE silently return MATCH ALL instead of raising error #22 — Scalar functions in WHERE (LOWER(col) = 'x', qty + 1 = 5, NOT (...), IN (2+1, 7), BETWEEN lo AND hi) silently fell through to FilterOp::MatchAll. DELETE WHERE LOWER(...) would wipe the table; UPDATE WHERE LOWER(...) would touch every row.
• UPDATE SET col = col + N (column arithmetic) not evaluated — errors on strict, silently corrupts on schemaless #23 — UPDATE t SET n = n + 1 (and NOW(), UPPER(col), CASE, concat, LEAST(...)) wrote format!(\"{expr:?}\") into the column instead of evaluating. Strict errored on re-encode; schemaless silently stored the debug AST as a string.
• ALTER COLLECTION x ADD COLUMN y rejected — router dispatcher missing branch #24 — ALTER COLLECTION x ADD COLUMN y ... (and docs-advertised DROP COLUMN / RENAME COLUMN / ALTER COLUMN TYPE) were rejected at parse time because the pgwire DDL router had no branch for them.

What changed

Scan filter path (nodedb-query/src/scan_filter, nodedb/src/control/planner/sql_plan_convert/filter.rs)

• New FilterOp::Expr variant carrying a SqlExpr payload on ScanFilter.
• Planner now produces expr_filter(root) for any WHERE expression it cannot reduce to (field, op, value) instead of falling through to match-all. Every fall-through in sql_expr_to_scan_filters now routes through the evaluator.
• matches_value, matches_binary, and matches_binary_indexed all evaluate FilterOp::Expr against the row via SqlExpr::eval.
• Planner desugars parser-only variants (NOT, BETWEEN, InList, Like, IsNull) into the evaluator's equivalent AST nodes during sql_expr_to_bridge_expr.
• Bulk update/delete now treat empty filter_bytes as "match every row" instead of a zerompk decode error.

UPDATE assignment path (bridge::physical_plan::UpdateValue, handlers/point/update.rs, handlers/bulk_dml.rs)

• New UpdateValue::{Literal(Vec<u8>), Expr(SqlExpr)} enum carrying both pre-encoded literals and unevaluated expressions across the SPSC bridge.
• PointUpdate.updates and BulkUpdate.updates take Vec<(String, UpdateValue)>.
• Planner (assignments_to_update_values) converts non-literal RHS via sql_expr_to_bridge_expr; KV FieldSet now errors loudly on non-literal RHS instead of silently dropping fields.
• UPDATE handler snapshots the current row, evaluates each Expr assignment against that snapshot (PostgreSQL-style single-pass semantics), and emits the result into the doc.
• Fast binary-merge path still taken when every RHS is literal.
• check_generated_readonly / needs_recomputation helpers made generic over the payload type so literal and expression updates share one implementation.

UPSERT ON CONFLICT DO UPDATE (plan_insert, SqlPlan::Upsert, DocumentOp::Upsert, handlers/upsert.rs)

• plan_insert detects ON CONFLICT ... DO UPDATE SET in the AST and reroutes to a new plan_upsert_with_on_conflict path that carries the assignments.
• UpsertParams, SqlPlan::Upsert, and DocumentOp::Upsert all gain on_conflict_updates: Vec<(String, UpdateValue)>.
• execute_upsert applies those assignments against the existing row (evaluating expressions against a pre-update snapshot) instead of merging inserted fields.

ALTER COLLECTION column ops (pgwire/ddl/collection/alter/)

• New router branches for ALTER COLLECTION ADD COLUMN, DROP COLUMN, RENAME COLUMN, and ALTER COLUMN ... TYPE ....
• ADD COLUMN reuses the existing strict-schema handler. DROP/RENAME/ALTER TYPE are new handlers that mutate StrictSchema, bump version, propose via Raft, and refresh the Data Plane cache. Type changes are restricted to same-discriminant aliases (e.g. INT ↔ BIGINT); cross-type changes error loudly with an explanation rather than silently corrupting existing rows.

Structural hygiene on the fix path
Four pre-existing size violations were on files this fix needed to touch. Each was split into a directory before new code was added:

mod.rs files are pub mod + pub use only per project convention.

Shared evaluator hygiene (nodedb-query/src/expr/eval.rs)

• eval() and eval_with_old() previously duplicated ~140 lines of identical AST walking with a different column resolver. Extracted a private RowScope struct and a shared eval_scope walker; public methods now just build a scope and delegate. One traversal, one place to fix.
• Replaced .expect(\"list non-empty\") in the InList desugaring with a .reduce(...).unwrap_or(...) that falls back to the already-computed empty-list sentinel.

Test plan

All three originally-reported bugs have positive regression coverage asserting the correct behavior (not the current broken behavior). The coverage was widened along the same root-cause code paths — filter.rs fall-throughs, value.rs catch-all, router gaps — to catch every docs-advertised sibling of each bug.

• 24/24 integration tests pass in the three affected test files:
  • nodedb/tests/sql_transactions.rs — ALTER ADD/DROP/RENAME/ALTER TYPE on strict collections
  • nodedb/tests/sql_where_expressions.rs — LOWER/UPPER/NOT/BETWEEN/IN-with-expression/column-arithmetic in WHERE, including DELETE and UPDATE scoping
  • nodedb/tests/sql_update_expressions.rs — column arithmetic, NOW(), UPPER, concat, CASE, LEAST on strict + schemaless, plus UPSERT DO UPDATE SET
• 2121/2121 `nodedb` lib unit tests pass
• 331/331 `nodedb-query` unit tests pass
• `scripts/test.sh` full pgwire SQL suite passes end-to-end — no new errors, only pre-existing DROP-before-CREATE noise
• `cargo clippy -p nodedb -p nodedb-query -p nodedb-sql --all-targets -- -D warnings` clean
• `cargo fmt --all` clean

Closes

• Closes Scalar functions in WHERE silently return MATCH ALL instead of raising error #22
• Closes UPDATE SET col = col + N (column arithmetic) not evaluated — errors on strict, silently corrupts on schemaless #23
• Closes ALTER COLLECTION x ADD COLUMN y rejected — router dispatcher missing branch #24