claude@clouddev1
12395a9a6c
`create table … with pk` now parses the column-constraint suffix; combined with the commit-1 db layer, a constrained table works end to end. - A shared constraint-suffix grammar fragment — `not null`, `unique`, `default <literal>` — sits after each column's `(type)` group; `build_create_table` walks the matched path per column and folds the constraints into `ColumnSpec`. - §9 redundancy check: every `with pk` column is a primary-key column, so `not null` (any) and `unique` (single-column PK) are rejected with a friendly error (`parse.custom.constraint_redundant_on_pk`). - `project.yaml` round-trip: `ColumnSchema` gains `not_null` / `default`; the YAML reader/writer and `build_read_schema` carry them, so `rebuild` / `export` / `import` preserve constraints. - ADR-0029 §2.1's example corrected — `create table` columns are all PK columns, so its suffix is for `default` / `check`; `docs/simple-mode-limitations.md` records that non-PK columns at create time need advanced mode. CHECK is deferred to the next commit. 1184 tests pass (+7); clippy clean.
51 lines
1.9 KiB
Markdown
51 lines
1.9 KiB
Markdown
# Simple-mode query limitations
|
|
|
|
Simple mode's DSL query surface is deliberately a *subset*
|
|
of SQL. The DSL is a teaching on-ramp; advanced mode (raw
|
|
SQL) is the full surface. This document is the running
|
|
list of what a simple-mode query cannot express that
|
|
advanced-mode SQL can.
|
|
|
|
It serves two audiences:
|
|
|
|
- **Students** — each entry is the seed of a short
|
|
explanation of why the boundary exists and what to use
|
|
instead (often: switch to advanced mode).
|
|
- **Designers** — the consolidated list feeds the future
|
|
`Q4` SQL-subset specification: the inverse view of what
|
|
the supported subset deliberately leaves out.
|
|
|
|
The list grows as new simple-mode surface lands; each
|
|
entry names the ADR that drew the boundary.
|
|
|
|
## WHERE expressions (ADR-0026)
|
|
|
|
- **Comparison operands are a column or a literal**, not a
|
|
nested expression. `(a > b) = (c > d)` — comparing two
|
|
boolean sub-expressions — cannot be written. Parentheses
|
|
group boolean sub-expressions, not comparison operands.
|
|
- **A bare column is not a boolean.** A predicate always
|
|
has an operator: write `Active = true`, not `Active`.
|
|
- **No arithmetic** in expressions (`Price * 1.1`).
|
|
- **No string concatenation.**
|
|
- **No scalar functions** (`upper(Name)`, `length(x)`, …).
|
|
- **No subqueries**, and no `EXISTS`.
|
|
|
|
## Query shape (ADR-0026)
|
|
|
|
- **No `ORDER BY`.** `show data … limit <n>` orders
|
|
implicitly by the primary key; explicit ordering is not
|
|
yet available.
|
|
- **No `LIMIT … OFFSET`** — `limit` takes a row count
|
|
only.
|
|
|
|
## Table creation (ADR-0029)
|
|
|
|
- **`create table` declares only primary-key columns.**
|
|
`create table T with pk …` makes every listed column part
|
|
of the primary key; there is no simple-mode syntax for a
|
|
non-PK column in the same statement. Non-PK columns are
|
|
added afterward with `add column`. Creating a table with a
|
|
mix of PK and non-PK columns in one statement needs
|
|
advanced-mode `CREATE TABLE` syntax.
|