docs: fix remaining stale contract claims

Audit of the merged engine changes found stale statements: RETURNING was still
listed as unsupported, ON CONFLICT as primary-key-only, CHECK/FOREIGN KEY as
discarded instead of rejected, JSON functions as unsupported, and several TLS
passages still said the proxy declines SSL. Correct those, document RETURNING
syntax, the unique-index conflict target, the failed-COMMIT idle state, and the
rowid wire type.

src/content/docs/sql-reference/compatibility.md

@@ -99,7 +99,7 @@ Unsupported syntax normally returns an error. The items above are called out sep
 | `INSERT OR IGNORE`, `REPLACE`, and related SQLite conflict modes | Supported | Supported | Different syntax |
 | `ON CONFLICT DO NOTHING` | Supported for primary-key and unique-index targets | Supported for unique constraints | Supported for unique constraints |
 | `ON CONFLICT DO UPDATE` | Supported for primary-key and unique-index targets, including `excluded` | Supported for unique constraints | Supported for unique constraints |
-| `RETURNING` | Unsupported | Supported since 3.35 | Supported |
+| `RETURNING` | Supported for `INSERT`, `UPDATE`, and `DELETE` | Supported since 3.35 | Supported |
 | `TRUNCATE` | Unsupported | Unsupported | Supported |
 
 ## Schema and constraints
@@ -168,7 +168,7 @@ PizzaSQL accepts many familiar type names but does not implement PostgreSQL's st
 | SQLite date and time functions | Supported | Supported | Different function set |
 | `last_insert_rowid()`, `changes()`, `total_changes()` | Supported; session-local | Supported | Unsupported |
 | PostgreSQL date and time functions | Unsupported | Unsupported | Supported |
-| JSON functions | Unsupported | Available with SQLite JSON support | Supported |
+| JSON functions | Supported: TEXT storage plus JSON1 scalar functions and `json_group_array`; no `JSONB` or `->`/`->>` | Available with SQLite JSON support | Supported |
 | Window functions | Partial; `ROW_NUMBER()` only | Supported | Supported |
 
 ## Transactions

src/content/docs/sql-reference/overview.md

@@ -29,7 +29,7 @@ SELECT [DISTINCT] cols FROM table [WHERE ...] [GROUP BY ...] [HAVING ...]
 INSERT INTO t (cols) VALUES (...), (...);
 INSERT INTO t SELECT ...;
 INSERT OR REPLACE/IGNORE/FAIL/ABORT INTO t ...;
-INSERT INTO t ... ON CONFLICT (pk) DO NOTHING | DO UPDATE SET c = v, ...;
+INSERT INTO t ... ON CONFLICT (col, ...) DO NOTHING | DO UPDATE SET c = v, ...;
 UPDATE t SET c = v, ... WHERE ...;
 DELETE FROM t WHERE ...;
 
@@ -57,7 +57,6 @@ EXPLAIN ...; EXPLAIN QUERY PLAN ...;
 PizzaSQL is intentionally small. These features are not implemented at all — they will be rejected by the parser, not silently mishandled:
 
 - **Window functions** — only `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)`; other window functions and frame clauses are not implemented.
-- **`RETURNING`** — `INSERT`/`UPDATE`/`DELETE` do not return rows.
 - **`WITHOUT ROWID`** tables.
 - **Triggers**, **stored procedures**, **prepared SQL in the engine** (the PG driver handles parameters client-side).
 - **`GLOB`** — the keyword exists but is not wired up as an operator; `x GLOB 'a*'` is a parse error.
@@ -66,7 +65,7 @@ A second group of features *parses* but has no effect or is only partially imple
 
 - `RIGHT JOIN` and `FULL [OUTER] JOIN` parse but return an empty result — they are not executed. Use `LEFT JOIN` and reorder.
 - `NATURAL JOIN` and `USING (cols)` parse but the condition is ignored.
-- `UNIQUE`, `CHECK`, and `FOREIGN KEY` constraints parse but are **not enforced** (see [Constraints](/sql-reference/constraints/)).
+- `CHECK` and `FOREIGN KEY` constraints are **rejected at DDL** with SQLSTATE `0A000`; `UNIQUE` constraints and unique indexes are enforced (see [Constraints](/sql-reference/constraints/)).
 - `AUTOINCREMENT` parses but has **no behaviour** beyond ordinary `INTEGER PRIMARY KEY` rowid generation.
 - `LIKE ... ESCAPE 'x'` — the `ESCAPE` clause is parsed and ignored.
 

src/content/docs/sql-reference/statements.md

@@ -51,29 +51,31 @@ INSERT OR REPLACE INTO table ...;
 INSERT OR IGNORE INTO table ...;
 INSERT OR FAIL INTO table ...;
 INSERT OR ABORT INTO table ...;
-INSERT INTO table ... ON CONFLICT [(pk)] DO NOTHING;
-INSERT INTO table ... ON CONFLICT [(pk)] DO UPDATE SET col = expr, ...;
+INSERT INTO table ... ON CONFLICT [(col, ...)] DO NOTHING;
+INSERT INTO table ... ON CONFLICT [(col, ...)] DO UPDATE SET col = expr, ...;
+INSERT INTO table ... RETURNING expr, ...;
 ```
 
 - Omitting the column list targets all columns in declaration order.
 - `INSERT ... SELECT` bulk-inserts the materialized result.
-- **Conflict handling** is driven by the primary key only:
-  - `INSERT OR IGNORE` silently skips duplicate-PK rows.
+- **Conflict handling** applies to the primary key and to unique indexes:
+  - `INSERT OR IGNORE` silently skips rows that would violate a primary key or unique index.
   - `INSERT OR REPLACE` deletes the conflicting row and inserts the new one.
-  - `INSERT OR FAIL`/`OR ABORT` abort on the first duplicate.
-  - `ON CONFLICT (target) DO NOTHING` / `DO UPDATE SET ...` work only when the conflict is on the primary key; the `(target)` list must name the PK column (or be omitted).
-- Auto-generated integer primary keys (and the implicit rowid) are assigned when no PK value is supplied. There is **no `RETURNING`**, but `SELECT last_insert_rowid()` returns the rowid of the most recent successful `INSERT` on this connection (see [Functions](/sql-reference/functions/)).
+  - `INSERT OR FAIL`/`OR ABORT` abort on the first conflict.
+  - `ON CONFLICT (target) DO NOTHING` / `DO UPDATE SET ...` accept a primary-key or unique-index column list; omit the list for any conflict. `excluded.column` refers to the value proposed by the INSERT.
+- Auto-generated integer primary keys (and the implicit rowid) are assigned when no PK value is supplied. `SELECT last_insert_rowid()` returns the rowid of the most recent successful `INSERT` on this connection (see [Functions](/sql-reference/functions/)).
+- `RETURNING expr, ...` returns the inserted rows (including generated keys and defaults) instead of a bare command tag.
 
 ## UPDATE and DELETE
 
 ```sql
-UPDATE table SET col = expr, ... WHERE condition;
-DELETE FROM table WHERE condition;
+UPDATE table SET col = expr, ... [WHERE condition] [RETURNING expr, ...];
+DELETE FROM table [WHERE condition] [RETURNING expr, ...];
 ```
 
 - Both evaluate the `WHERE` condition per row. `UPDATE` evaluates `SET` expressions against the row's current values, so `SET balance = balance + 100` works.
 - Omitting `WHERE` affects every row.
-- No `RETURNING`, no `ORDER BY`/`LIMIT` on `UPDATE`/`DELETE`.
+- `RETURNING` returns the affected rows. `ORDER BY`/`LIMIT` on `UPDATE`/`DELETE` are not supported.
 
 ## CREATE TABLE
 
@@ -176,4 +178,4 @@ DETACH DATABASE alias;
 
 ## Not supported
 
-These are rejected at parse time: `RETURNING`, `WITHOUT ROWID`, `TRUNCATE`, `UPSERT` (beyond the `OR`/`ON CONFLICT` forms), triggers, and `CREATE SCHEMA`/roles. Window functions other than `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)` are also rejected.
+These are rejected at parse time: `WITHOUT ROWID`, `TRUNCATE`, `UPSERT` (beyond the `OR`/`ON CONFLICT` forms), triggers, and `CREATE SCHEMA`/roles. Window functions other than `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)` are also rejected.