docs(sql): add SQL extensions section and expand existing pages

Add eight new SQL reference pages covering JSON operators, COPY,
LISTEN/NOTIFY, custom types, window frames, lateral subqueries,
recursive CTEs, and grouping sets. Register them under a new
"SQL Extensions" sidebar group in oxidoc.toml, alongside a new
"SQL Index" group for the index page.

Expand existing pages with RETURNING clause examples, UPDATE/DELETE
FROM join syntax, additional JOIN types, RRF fusion scoring details,
FTS ranking and highlighting functions, and CRDT merge strategy notes.

Author: farhan-syah

docs/sql/copy.rdx

@@ -0,0 +1,89 @@
+---
+title: COPY FROM / COPY TO
+description: Bulk import and export of collections using NDJSON, JSON array, and CSV formats.
+---
+
+# COPY FROM / COPY TO
+
+`COPY` moves data between a NodeDB collection and a file on the server's filesystem. It is the fastest way to load or dump large datasets.
+
+## COPY FROM — import
+
+```sql
+COPY <collection> FROM '<path>' [WITH (FORMAT <fmt> [, DELIMITER '<char>'] [, HEADER <bool>])]
+```
+
+Reads the file at `<path>` on the server and inserts every record into `<collection>`. The format is either specified explicitly or auto-detected from the file extension.
+
+### Auto-detected formats
+
+| Extension           | Format       |
+| ------------------- | ------------ |
+| `.ndjson`, `.jsonl` | NDJSON       |
+| `.json`             | JSON array   |
+| `.csv`              | CSV          |
+
+### Examples
+
+```sql
+-- NDJSON (one JSON object per line) — format auto-detected from extension
+COPY users FROM '/data/users.ndjson';
+
+-- JSON array (a single top-level array of objects)
+COPY users FROM '/data/users.json' WITH (FORMAT json_array);
+
+-- CSV with header row (default when FORMAT csv)
+COPY orders FROM '/data/orders.csv' WITH (FORMAT csv);
+
+-- CSV without header row
+COPY orders FROM '/data/orders.csv' WITH (FORMAT csv, HEADER false);
+
+-- CSV with non-comma delimiter
+COPY products FROM '/data/products.tsv' WITH (FORMAT csv, DELIMITER '\t');
+```
+
+### WITH options
+
+| Option      | Values                          | Default           | Description                             |
+| ----------- | ------------------------------- | ----------------- | --------------------------------------- |
+| `FORMAT`    | `ndjson`, `json_array`, `csv`   | auto from extension | File format                           |
+| `DELIMITER` | Any single character            | `,`               | Field separator (CSV only)              |
+| `HEADER`    | `true` / `false`                | `true`            | Whether the first CSV row is a header   |
+
+## COPY TO — export
+
+```sql
+COPY <collection> TO '<path>' [WITH (FORMAT <fmt> [, DELIMITER '<char>'] [, HEADER <bool>])]
+COPY (SELECT ...) TO '<path>' [WITH (...)]
+```
+
+Writes every row from `<collection>` (or the result of a SELECT) to a file at `<path>` on the server. The format is auto-detected from the extension or specified explicitly.
+
+### Examples
+
+```sql
+-- Export entire collection as NDJSON
+COPY users TO '/exports/users.ndjson';
+
+-- Export with explicit format
+COPY users TO '/exports/users.json' WITH (FORMAT json_array);
+
+-- Export as CSV with header
+COPY orders TO '/exports/orders.csv' WITH (FORMAT csv);
+
+-- Export the result of a query
+COPY (SELECT id, name, email FROM users WHERE status = 'active')
+    TO '/exports/active_users.csv' WITH (FORMAT csv);
+
+-- Query export as NDJSON
+COPY (SELECT * FROM orders WHERE created_at > '2025-01-01')
+    TO '/exports/recent_orders.ndjson';
+```
+
+## Notes
+
+- Paths are resolved on the **server** filesystem. The client never streams file bytes — this is not `\copy` (psql client-side copy).
+- `COPY FROM STDIN` is reserved for the backup/restore path and is not available as a general import mechanism.
+- Rows that fail type coercion during import are rejected with a parse error; no partial-row insertion occurs.
+- `COPY TO` is non-transactional: the file is written even if the session is later rolled back.
+- The `COPY (SELECT ...) TO` form supports all SELECT features including JOINs, CTEs, and WHERE clauses.

docs/sql/crdt-operations.rdx

@@ -23,4 +23,4 @@ Applies a Loro CRDT delta to the document. On Origin, the delta goes through Raf
 
 ## Conflict Policies
 
-Conflict policies (last-writer-wins, field-merge, custom) are configured per-collection at create time and via the native NodeDB protocol's `ALTER POLICY` command. SQL DDL for inspecting and updating conflict policies — `SHOW CONFLICT POLICY ON <collection>` and `ALTER COLLECTION ... SET ON CONFLICT ...` — is wired in the v0.1.0 release alongside the rest of the SQL surface. See the protocol reference for the native-protocol form, and [CRDT Sync](/docs/crdt-sync/overview) for full sync protocol details.
+Conflict policies (last-writer-wins, field-merge, custom) are configured per-collection at create time and via the native NodeDB protocol's `ALTER POLICY` command. SQL DDL for inspecting and updating conflict policies — `SHOW CONFLICT POLICY ON <collection>` and `ALTER COLLECTION ... SET ON CONFLICT ...` — is available alongside the rest of the SQL surface. See the protocol reference for the native-protocol form, and [CRDT Sync](/docs/crdt-sync/overview) for full sync protocol details.

docs/sql/custom-types.rdx

@@ -0,0 +1,112 @@
+---
+title: Custom Types
+description: CREATE TYPE for enums and composite types, ALTER TYPE ADD VALUE, and DROP TYPE.
+---
+
+# Custom Types
+
+NodeDB supports user-defined types in two forms: **enum types** (a fixed, ordered set of string labels) and **composite types** (a named record with typed fields). Both can be used as column types in `CREATE COLLECTION` and `CREATE TABLE` statements.
+
+## Enum Types
+
+```sql
+CREATE TYPE <name> AS ENUM ('<label1>', '<label2>', ...)
+```
+
+Defines a type whose valid values are the listed labels. Labels are case-sensitive strings. Duplicates are rejected at definition time.
+
+```sql
+CREATE TYPE order_status AS ENUM ('pending', 'processing', 'shipped', 'delivered', 'cancelled');
+
+CREATE TYPE priority AS ENUM ('low', 'medium', 'high', 'critical');
+```
+
+### Using enum types
+
+```sql
+CREATE COLLECTION orders (
+    id TEXT PRIMARY KEY,
+    status order_status,
+    priority priority
+) WITH (engine = 'document_strict');
+
+INSERT INTO orders (id, status, priority) VALUES ('o1', 'pending', 'high');
+
+SELECT * FROM orders WHERE status = 'pending';
+```
+
+### Adding a new label
+
+```sql
+ALTER TYPE order_status ADD VALUE 'on_hold';
+```
+
+The new value is appended to the end of the enum. Existing rows are unaffected. `ADD VALUE` is the only supported `ALTER TYPE` form.
+
+## Composite Types
+
+```sql
+CREATE TYPE <name> AS (<field1> <type1>, <field2> <type2>, ...)
+```
+
+Defines a named record type. Each field has a name and a SQL data type.
+
+```sql
+CREATE TYPE address AS (
+    street TEXT,
+    city   TEXT,
+    zip    TEXT,
+    country TEXT
+);
+
+CREATE TYPE money_amount AS (
+    value    FLOAT,
+    currency TEXT
+);
+```
+
+### Using composite types
+
+```sql
+CREATE COLLECTION users (
+    id      TEXT PRIMARY KEY,
+    name    TEXT,
+    billing address
+) WITH (engine = 'document_strict');
+
+INSERT INTO users (id, name, billing)
+VALUES ('u1', 'Alice', ROW('123 Main St', 'Springfield', '12345', 'US'));
+
+SELECT billing.city FROM users WHERE id = 'u1';
+```
+
+## Inspecting types
+
+```sql
+SHOW TYPES;
+```
+
+Lists all user-defined types in the current tenant, their kind (enum or composite), and their labels or fields.
+
+## Dropping types
+
+```sql
+DROP TYPE order_status;
+DROP TYPE IF EXISTS address;
+```
+
+`DROP TYPE` is **protected**: it fails if any collection has a column of that type. Drop or alter the dependent collections first, then drop the type.
+
+## OIDs
+
+Custom types are assigned OIDs starting at 70001. These appear in `pg_type` catalog queries and in the pgwire type-description messages for columns that use the custom type.
+
+<Callout kind="warning" title="pgwire binary codec">
+Custom types are currently sent over pgwire in TEXT format regardless of the client's requested format. Binary-format decoding for custom type OIDs is not yet implemented. Most PostgreSQL client libraries fall back gracefully to text parsing.
+</Callout>
+
+## Validation rules
+
+- **Enum labels** must be non-empty strings. Duplicate labels within the same type are rejected.
+- **Composite fields** must have distinct names within the same type. The field types can be any built-in SQL type; nested composite types are not yet supported.
+- **Type names** are lowercased and must be unique within the tenant.

docs/sql/fulltext-search.rdx

@@ -28,6 +28,61 @@ CJK text is automatically tokenized via character bigrams:
 SELECT title FROM articles WHERE text_match(body, '全文検索');
 ```
 
+## NOT Operator
+
+Exclude documents that match specific terms using the `NOT` keyword or the `-` prefix (Lucene-style, no space before the term).
+
+Both forms require at least one positive term — a query consisting only of negations is rejected.
+
+```sql
+-- Exclude documents that mention 'python'
+SELECT title FROM articles
+WHERE text_match(body, 'rust NOT python');
+
+-- Multiple exclusions
+SELECT title FROM articles
+WHERE text_match(body, 'database NOT mysql NOT oracle');
+
+-- Lucene-style dash prefix (equivalent to NOT)
+SELECT title FROM articles
+WHERE text_match(body, 'database -mysql -oracle');
+```
+
+Parenthesised NOT groups are not supported. Use flat negations:
+
+```sql
+-- Not supported:  rust NOT (python OR ruby)
+-- Supported:      rust NOT python NOT ruby
+SELECT title FROM articles
+WHERE text_match(body, 'rust NOT python NOT ruby');
+```
+
+## Synonym Groups
+
+A synonym group makes the FTS engine treat a set of terms as interchangeable during indexing and querying. When a document contains any term in the group it also matches queries for any other term in the group.
+
+```sql
+-- Define synonyms
+CREATE SYNONYM GROUP db_terms AS ('database', 'db', 'datastore');
+CREATE SYNONYM GROUP ml_terms AS ('machine learning', 'ml', 'artificial intelligence', 'ai');
+
+-- Now a query for 'db' also matches documents that contain 'database' or 'datastore'
+SELECT title FROM articles WHERE text_match(body, 'db performance');
+```
+
+### Managing synonym groups
+
+```sql
+-- List all groups
+SHOW SYNONYM GROUPS;
+
+-- Drop a group
+DROP SYNONYM GROUP db_terms;
+DROP SYNONYM GROUP IF EXISTS ml_terms;
+```
+
+Synonym group names are case-insensitive. Terms within a group are stored lowercased. Duplicate terms within the same group are rejected at creation time.
+
 ## Hybrid Search (BM25 + Vector)
 
 ```sql

docs/sql/fusion-rrf.rdx

@@ -48,6 +48,32 @@ SEARCH entities USING FUSION(
 
 Vector search finds seed nodes, graph BFS expands context, RRF merges both rankings.
 
+## Three-Source Fusion (Vector + Text + Graph)
+
+When you want vector similarity, BM25 text relevance, and graph context all merged in one pass, add the `BM25 '<query>' ON '<field>'` leg to the `SEARCH … USING FUSION` DSL. The `RRF_K` tuple becomes a triple.
+
+```sql
+SEARCH entities USING FUSION(
+    ARRAY[0.1, 0.3, -0.2, ...]
+    VECTOR_FIELD 'embedding' VECTOR_TOP_K 50
+    BM25 'transformer attention' ON 'body'
+    DEPTH 2 LABEL 'related_to'
+    TOP 10 RRF_K (60.0, 35.0, 50.0)
+);
+```
+
+The three `RRF_K` values correspond to the vector leg, the graph expansion leg, and the BM25 leg respectively. When all three are present the planner routes through the three-source RRF plan variant.
+
+The two-source `GRAPH RAG FUSION ON … BM25 '…' ON '…'` form also accepts the extra text leg inline:
+
+```sql
+GRAPH RAG FUSION ON entities
+  QUERY $embedding VECTOR_FIELD 'embedding' VECTOR_TOP_K 50
+  BM25 'transformer attention' ON 'body'
+  EXPANSION_DEPTH 2 EDGE_LABEL 'related_to' FINAL_TOP_K 10
+  RRF_K (60.0, 35.0, 50.0);
+```
+
 ## Cross-Model Queries
 
 All engines share the same snapshot. A query that combines vector similarity, graph traversal, spatial filtering, and document field access sees a consistent point-in-time view.