rust/lancedb
1
0
Fork 0
mirror of https://github.com/lancedb/lancedb.git synced 2026-10-20 18:52:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: clean up prose flagged by the shared Vale rules (#4596)

Browse Source 
The existing docs have 254 findings from our shared Vale rules.
Contributors would otherwise inherit these when editing the same lines.

Clean up the prose across 80 pages: correct product names and a repeated
word, simplify a few phrases, and replace dashes with punctuation that
fits each sentence. The pinned Vale scan now reports zero findings, with
no suppressions.
This commit is contained in:
Brendan Clement
2026-10-19 13:45:55 -07:00
committed by GitHub
parent 1ad97b148b
commit 198812fd53
80 changed files with 252 additions and 252 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/web/sql/data-types.mdx
+2 -2
View File
@@ -96,7 +96,7 @@ JSON scalar index. See [Functions](/sql/scalar-functions#json).
### Blobs {#blobs}
A blob column is read either as its binary contents or as a **description** — a
A blob column is read either as its binary contents or as a **description**: a
pointer plus metadata, without fetching the bytes. That choice changes the
column's Arrow type, and therefore the schema your query sees.
@@ -121,7 +121,7 @@ error naming the missing feature rather than an unknown-function error, and the
spatial index is gated the same way.
</Warning>
Geometry can still be stored -- it is binary, and binary columns work -- but
Geometry can still be stored (it is binary, and binary columns work), but
nothing interprets it. Filter on a bounding box held in ordinary numeric
columns if you need spatial predicates today.
docs/web/sql/ddl/function.mdx
+4 -4
View File
@@ -23,7 +23,7 @@ Parameter and result types are Arrow type names, not SQL ones: `int64`,
unless it is declared `NOT NULL`.
The body is Python source. Its dependencies are declared with it and are part
of the **immutable function version** -- changing one produces a new version
of the **immutable function version**. Changing one produces a new version
rather than altering the registered one, so a column filled by an earlier
version is unaffected.
@@ -40,7 +40,7 @@ version is unaffected.
| | |
| --- | --- |
| `LANGUAGE` other than `python` | refused |
| `pip` and `conda` together | refused -- pick one |
| `pip` and `conda` together | refused (pick one) |
| `conda_channels` without `conda` | refused |
| `gpu` set to anything but `'true'` | refused |
| An empty body | refused |
@@ -69,13 +69,13 @@ DROP FUNCTION IF EXISTS embed WITH (version = '1')
DROP FUNCTION embed WITH (version = '1', cascade = 'true')
```
`version` is required -- a function is a set of immutable versions, and
`version` is required: a function is a set of immutable versions, and
dropping is always of one specific version, never "the function" as a whole.
<Warning>
Without `cascade = 'true'`, dropping a version that a column still pins fails
rather than breaking that column silently. Passing it drops the version and
lets columns pinned to it stop refreshing -- they keep their last-filled
lets columns pinned to it stop refreshing. They keep their last-filled
values, per [Guarantees](/basics/guarantees#jobs).
</Warning>
docs/web/sql/ddl/index.mdx
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: "Index"
sidebarTitle: "Index"
description: "CREATE INDEX and DROP INDEX — one column, with the algorithm chosen by USING."
description: "CREATE INDEX and DROP INDEX: one column, with the algorithm chosen by USING."
icon: bolt
keywords: ["create index", "drop index", "sql"]
---
docs/web/sql/ddl/job.mdx
+5 -5
View File
@@ -8,8 +8,8 @@ keywords: ["show jobs", "show errors", "pause job", "resume job", "cancel job",
<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
A [job](/basics/jobs) is not a catalog object -- it has no schema and is not
namespaced -- but it has its own SQL statements, grouped here the same way the
A [job](/basics/jobs) is not a catalog object (it has no schema and is not
namespaced), but it has its own SQL statements, grouped here the same way the
catalog objects are.
## SHOW JOBS {#show}
@@ -18,7 +18,7 @@ catalog objects are.
SHOW JOBS
```
Every job the server knows about -- id, type, state, creation time. The SQL
Every job the server knows about: id, type, state, creation time. The SQL
counterpart of `list_jobs`.
## SHOW ERRORS {#errors}
@@ -44,7 +44,7 @@ fewer filled rows than you expected.
| Tables the server does not open directly | not supported |
Without `FOR JOB` this surveys recent failures and stops at 32 jobs. When the
listing stops at your `LIMIT`, the message says so -- narrow with `FOR JOB`
listing stops at your `LIMIT`, the message says so. Narrow with `FOR JOB`
rather than raising the limit blindly.
## PAUSE JOB {#pause}
@@ -66,7 +66,7 @@ CANCEL JOB 'j-ci-abc-def'
```
The job id is always a quoted string literal. All three take exactly one and
nothing after it -- a second token on the line is a syntax error rather than
nothing after it: a second token on the line is a syntax error rather than
being ignored.
<Note>
docs/web/sql/ddl/materialized-view.mdx
+3 -3
View File
@@ -8,8 +8,8 @@ keywords: ["materialized view", "create materialized view", "show materialized v
<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
A materialized view stores a query's result as rows, kept current by a refresh
-- the counterpart to a [view](/sql/ddl/view), which stores only the query.
A materialized view stores a query's result as rows, kept current by a refresh.
It is the counterpart to a [view](/sql/ddl/view), which stores only the query.
<Note>
Materialized views are off by default in LanceDB Enterprise and have to be enabled
@@ -51,7 +51,7 @@ and compatibility notes for older server versions.
## Dropping one {#drop}
A materialized view **is** a table, so it is dropped with
[`DROP TABLE`](/sql/ddl/table#drop) -- which is also why dropping one removes
[`DROP TABLE`](/sql/ddl/table#drop). For the same reason, dropping one removes
stored rows, unlike dropping a [view](/sql/ddl/view#drop).
<Note>
docs/web/sql/ddl/namespace.mdx
+4 -4
View File
@@ -1,14 +1,14 @@
---
title: "Namespace"
sidebarTitle: "Namespace"
description: "CREATE SCHEMA and DROP SCHEMA — the SQL spelling of namespace DDL."
description: "CREATE SCHEMA and DROP SCHEMA: the SQL spelling of namespace DDL."
icon: folder-tree
keywords: ["namespace", "schema", "create schema", "drop schema", "sql"]
---
<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
A [namespace](/management/namespace) is addressed in SQL as a `SCHEMA` -- the
A [namespace](/management/namespace) is addressed in SQL as a `SCHEMA`, the
standard's name for the same concept.
## CREATE SCHEMA {#create}
@@ -39,8 +39,8 @@ DROP SCHEMA `a$b` RESTRICT
<Warning>
`CASCADE` is rejected: **"DROP SCHEMA CASCADE is not supported; drop the
objects inside first."** A namespace's tables, views and other objects must be
dropped explicitly before the namespace itself can go. `RESTRICT` -- the
default -- states that requirement rather than changing it.
dropped explicitly before the namespace itself can go. `RESTRICT` (the
default) states that requirement rather than changing it.
</Warning>
## What to read next {#next}
docs/web/sql/ddl/table.mdx
+8 -8
View File
@@ -15,7 +15,7 @@ CREATE TABLE documents (id BIGINT, title VARCHAR, created_at TIMESTAMP)
CREATE TABLE recent AS SELECT * FROM documents WHERE created_at > now() - INTERVAL '7 days'
```
Column types are Arrow types under SQL names -- see [Data types](/sql/data-types).
Column types are Arrow types under SQL names. See [Data types](/sql/data-types).
A table inside a [namespace](/sql/ddl/namespace) is written as a dotted path:
`prod.events.clicks`.
@@ -25,7 +25,7 @@ A table inside a [namespace](/sql/ddl/namespace) is written as a dotted path:
DESCRIBE documents
```
The table's columns and types, without a plan -- the SQL counterpart of
The table's columns and types, without a plan. The SQL counterpart of
`table.schema`.
## ALTER TABLE {#alter}
@@ -37,7 +37,7 @@ name.
SQL `ADD COLUMN` requires an `AS` binding, so a plain column such as
`ALTER TABLE t ADD COLUMN c INT` is rejected. Add an empty, nullable column
with the SDK instead -- see
with the SDK instead. See
[Add nullable columns](/management/table#schema-add-nullable-columns).
### A computed column {#computed-column}
@@ -47,7 +47,7 @@ ALTER TABLE t ADD COLUMN doubled AS value * 2
```
`AS <expression>` declares a [computed column](/feature-engineering/add-computed-column).
The column is committed empty and the expression is stored, not evaluated --
The column is committed empty and the expression is stored, not evaluated:
declaring one on a billion-row table costs what declaring one on an empty table
costs. [`REFRESH COLUMN`](/sql/dml/refresh) fills it.
@@ -129,9 +129,9 @@ rows a sample would draw from are not all in the fragments yet.
| --- | --- |
| `ALTER TABLE ... DROP COLUMN` | not supported |
Dropping, renaming, or retyping a column is an SDK operation --
[`drop_columns`](/management/table#schema) and
[`alter_columns`](/management/table#schema) -- not a SQL statement.
Dropping, renaming, or retyping a column is an SDK operation
([`drop_columns`](/management/table#schema) and
[`alter_columns`](/management/table#schema)), not a SQL statement.
## CLONE {#clone}
@@ -147,7 +147,7 @@ copying them, so it costs one metadata commit regardless of the source's size.
`AT` pins the point in the source's history to clone. A bare integer is a
version and a bare quoted string is a timestamp; `VERSION`, `TAG` and
`TIMESTAMP` say so explicitly, and a tag always needs its keyword -- a bare
`TIMESTAMP` say so explicitly, and a tag always needs its keyword: a bare
quoted string cannot be both a tag name and a timestamp.
<Warning>
docs/web/sql/ddl/view.mdx
+7 -7
View File
@@ -1,7 +1,7 @@
---
title: "View"
sidebarTitle: "View"
description: "CREATE VIEW and DROP VIEW — a saved query, evaluated when read."
description: "CREATE VIEW and DROP VIEW: a saved query, evaluated when read."
icon: eye
keywords: ["create view", "drop view", "sql", "catalog"]
---
@@ -9,7 +9,7 @@ keywords: ["create view", "drop view", "sql", "catalog"]
<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
A view stores a **query**, not rows. Reading it runs the query against current
data, so a view is never stale -- and never faster than the query it wraps. It
data, so a view is never stale, and never faster than the query it wraps. It
is the counterpart to a [materialized view](/sql/ddl/materialized-view), which
stores rows and is brought up to date by a refresh; both are
[catalog objects](/basics/catalog) defined by a query, differing only in when
@@ -27,8 +27,8 @@ FROM "documents" AS t1
INNER JOIN "categories" AS t2 ON t1.ints = t2.ints
```
The statement returns the view's schema -- column name, data type, nullability
-- resolved from the query at creation time. Anything the
The statement returns the view's schema (column name, data type, nullability),
resolved from the query at creation time. Anything the
[dialect](/sql/functions) supports can define one: joins, predicates,
aggregates, window functions.
@@ -50,7 +50,7 @@ the view would have produced and then discarded.
DROP VIEW "recent_matches"
```
Removes the saved query. Unlike dropping a table, no data is removed -- there
Removes the saved query. Unlike dropping a table, no data is removed: there
was none to begin with.
## Listing {#listing}
@@ -62,10 +62,10 @@ catalog distinguishes them:
| --- | --- |
| view names | the views in the database |
| table names | the tables |
| relation names | everything queryable -- both |
| relation names | everything queryable (both) |
Use the relation listing when the question is "what can I select from," and the
separate listings when the distinction matters -- before dropping, for
separate listings when the distinction matters: before dropping, for
instance, since dropping a view removes only the saved query while dropping a
table removes data.
docs/web/sql/dml/copy.mdx
+2 -2
View File
@@ -1,7 +1,7 @@
---
title: "Copy"
sidebarTitle: "Copy"
description: "COPY ... TO — writing a query result to object storage as files."
description: "COPY ... TO: writing a query result to object storage as files."
icon: file-export
keywords: ["copy", "export", "parquet", "sql"]
---
@@ -17,7 +17,7 @@ COPY (SELECT id, title FROM documents) TO 's3://bucket/export/' STORED AS PARQUE
```
Writes a query result to object storage. This is the export path when the
consumer is another engine rather than an application -- results land as files
consumer is another engine rather than an application: results land as files
rather than streaming to a client.
## What to read next {#next}
docs/web/sql/dml/delete.mdx
+2 -2
View File
@@ -1,7 +1,7 @@
---
title: "Delete"
sidebarTitle: "Delete"
description: "DELETE FROM ... WHERE — rows are marked, not erased."
description: "DELETE FROM ... WHERE: rows are marked, not erased."
icon: trash
keywords: ["delete", "sql"]
---
@@ -21,7 +21,7 @@ for as long as the version holding it survives
[retention](/maintenance/cleanup).
Commits a new table version, so [versioning](/management/table#versioning) and
the [write guarantees](/basics/guarantees#writes) apply -- including that the
the [write guarantees](/basics/guarantees#writes) apply, including that the
version advances even when the statement affects zero rows.
## What to read next {#next}
docs/web/sql/dml/insert.mdx
+2 -2
View File
@@ -18,7 +18,7 @@ INSERT INTO archive SELECT * FROM documents WHERE created_at < '2026-01-01'
server-side, without a round trip through your process.
Commits a new table version, so [versioning](/management/table#versioning) and
the [write guarantees](/basics/guarantees#writes) apply -- including that the
the [write guarantees](/basics/guarantees#writes) apply, including that the
version advances even when the statement affects zero rows.
## What to read next {#next}
@@ -28,6 +28,6 @@ version advances even when the statement affects zero rows.
The SDK equivalent.
</Card>
<Card title="Merge Insert" icon="code-merge" href="/ingestion/merge-insert">
Upsert -- matching incoming rows against existing keys -- has no SQL form.
Upsert (matching incoming rows against existing keys) has no SQL form.
</Card>
</CardGroup>
docs/web/sql/dml/refresh.mdx
+1 -1
View File
@@ -27,7 +27,7 @@ REFRESH COLUMN embedding ON documents WHERE created_at > '2026-01-01'
A refresh gives values to rows that lack them, recomputes rows whose inputs
changed, and **leaves other filled rows alone**. That makes it idempotent, cheap
to repeat as data arrives, and safe to re-run after a failure -- though a re-run
to repeat as data arrives, and safe to re-run after a failure, though a re-run
can recompute values the failed run had already written.
`WHERE` scopes the refresh, which is how you fill a slice and check it before
docs/web/sql/dml/update.mdx
+3 -3
View File
@@ -1,7 +1,7 @@
---
title: "Update"
sidebarTitle: "Update"
description: "UPDATE ... SET ... WHERE — and why it does not recompute derived columns."
description: "UPDATE ... SET ... WHERE, and why it does not recompute derived columns."
icon: pen
keywords: ["update", "sql"]
---
@@ -19,12 +19,12 @@ clause every row is updated.
<Warning>
An update does not recompute [computed columns](/feature-engineering/add-computed-column)
that derive from the column you changed. Those rows keep the value computed from
the old input until the next refresh recomputes them -- see
the old input until the next refresh recomputes them. See
[Guarantees](/basics/guarantees#jobs).
</Warning>
Commits a new table version, so [versioning](/management/table#versioning) and
the [write guarantees](/basics/guarantees#writes) apply -- including that the
the [write guarantees](/basics/guarantees#writes) apply, including that the
version advances even when the statement affects zero rows.
## What to read next {#next}
docs/web/sql/dql/aggregation.mdx
+1 -1
View File
@@ -32,7 +32,7 @@ SELECT category, source, count(*) FROM documents GROUP BY category, source
## Aggregate without grouping {#whole-table}
Omitting `GROUP BY` aggregates the whole table into one row -- the usual way to
Omitting `GROUP BY` aggregates the whole table into one row, which is the usual way to
ask how big something is:
```sql
docs/web/sql/dql/explain.mdx
+3 -3
View File
@@ -1,7 +1,7 @@
---
title: "Explain"
sidebarTitle: "Explain"
description: "EXPLAIN, EXPLAIN ANALYZE and EXPLAIN VERBOSE — reading and measuring a plan from SQL."
description: "EXPLAIN, EXPLAIN ANALYZE and EXPLAIN VERBOSE: reading and measuring a plan from SQL."
icon: map
keywords: ["explain", "explain analyze", "explain verbose", "query plan"]
---
@@ -20,7 +20,7 @@ EXPLAIN ANALYZE SELECT * FROM documents WHERE identifier < 1000
| `EXPLAIN VERBOSE <query>` | Adds intermediate optimizer plans on top of `EXPLAIN`. |
The result is a small relation with `plan_type` and `plan` columns, read
through the same client you use for regular queries -- see
through the same client you use for regular queries. See
[Connecting](/sql#connecting).
SQL plans and the SDK's
@@ -46,7 +46,7 @@ SQL can also add joins, aggregates and other operators:
| `FilterExec` above a search | the filter ran after search rather than pushing into it |
| `ANNSubIndex` / `ANNIvfPartition` | the vector index was used |
A `LanceScan` feeding a join is the common one worth acting on -- see
A `LanceScan` feeding a join is the common one worth acting on. See
[Joins](/sql/dql/join#performance).
For a table's columns and types without a plan, see
docs/web/sql/dql/fts.mdx
+7 -7
View File
@@ -1,7 +1,7 @@
---
title: "Full-Text Search"
sidebarTitle: "Full-Text Search"
description: "The fts() table function — match, fuzzy, phrase, boolean, boost and multi-match queries from SQL."
description: "The fts() table function: match, fuzzy, phrase, boolean, boost and multi-match queries from SQL."
icon: magnifying-glass
keywords: ["fts", "sql", "full text search", "fuzzy", "phrase", "boolean", "boost", "multi-match"]
---
@@ -9,7 +9,7 @@ keywords: ["fts", "sql", "full text search", "fuzzy", "phrase", "boolean", "boos
<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
Full-text search is a **table function**, `fts(table, query)`, rather than a
predicate -- it produces a relevance score alongside the matching rows, and a
predicate: it produces a relevance score alongside the matching rows, and a
`WHERE` clause has nowhere to put one. The two string-literal arguments are
the table name and a JSON-encoded query, built with the same query-builder
classes used from the SDK and serialized with `.to_json()`.
@@ -32,8 +32,8 @@ CREATE INDEX ON my_docs USING fts (text);
```
<Warning>
Phrase queries need position information, which costs extra index size --
add `WITH (with_position = true)` to `CREATE INDEX`. Without it,
Phrase queries need position information, which costs extra index size.
Add `WITH (with_position = true)` to `CREATE INDEX`. Without it,
[phrase queries](#phrase) find nothing. See
[FTS parameters](/indexing/fts-index#fts-parameters).
</Warning>
@@ -57,7 +57,7 @@ FROM fts('my_docs', '{"match":{"column":"text","terms":"puppy"}}')
LIMIT 5
```
By default the top 5 matches come back in **arbitrary order** -- select
By default the top 5 matches come back in **arbitrary order**. Select
`_score` and order by it for relevance ranking:
```sql
@@ -126,8 +126,8 @@ MultiMatchQuery("puppy", ["text", "category"], boosts=[2.0, 1.0]) # text weight
## Combining with SQL {#combining}
`fts()` is a relation, so it composes with the rest of the SQL surface --
filter, join, or aggregate over it same as any table:
`fts()` is a relation, so it composes with the rest of the SQL surface.
Filter, join, or aggregate over it same as any table:
```sql
SELECT id, text, category
docs/web/sql/dql/join.mdx
+3 -3
View File
@@ -24,14 +24,14 @@ JOIN categories AS c ON c.id = d.category_id
| `LEFT [OUTER] JOIN` | every left row, nulls where the right has no match |
| `RIGHT [OUTER] JOIN` | every right row |
| `FULL [OUTER] JOIN` | every row from both |
| `CROSS JOIN` | every combination -- the product of the two |
| `CROSS JOIN` | every combination (the product of the two) |
`USING (col)` is shorthand for an equality join on a shared column name, and
avoids repeating it in the select list.
## Across namespaces {#namespaces}
Tables in different [namespaces](/management/namespace) join by their dotted paths -- the
Tables in different [namespaces](/management/namespace) join by their dotted paths. The
catalog is one catalog, so there is nothing to federate:
```sql
@@ -56,7 +56,7 @@ ORDER BY hits DESC
```
That composition is the reason full-text search is a relation rather than a
predicate -- a `WHERE` clause has nowhere to put the relevance score.
predicate: a `WHERE` clause has nowhere to put the relevance score.
## Performance {#performance}
docs/web/sql/dql/sampling.mdx
+3 -3
View File
@@ -35,7 +35,7 @@ SELECT * FROM documents TABLESAMPLE SYSTEM (10)
| `SYSTEM` | `BLOCK` | **Lance fragments**, and takes whatever rows they hold |
`BERNOULLI` gives a genuinely uniform sample and reads across the whole table to
get it. `SYSTEM` reads far less -- it skips entire fragments -- but the sample is
get it. `SYSTEM` reads far less (it skips entire fragments), but the sample is
only as uniform as the data's layout. If rows were written in an order that
correlates with what you are measuring, a fragment sample inherits that
correlation.
@@ -46,7 +46,7 @@ independent row sampling. Omitting the method gives
## Repeatability {#repeatable}
Without a seed, every execution resamples -- running the same query twice gives
Without a seed, every execution resamples: running the same query twice gives
different rows. `REPEATABLE` fixes the draw:
```sql
@@ -98,5 +98,5 @@ would draw from are not all in the fragments yet.
## Sampling outside SQL {#sdk}
For a training loop rather than a query, the SDKs read a table in a shuffled
order without going through SQL at all -- see [Training](/training/data-loading), where a
order without going through SQL at all. See [Training](/training/data-loading), where a
permutation drives the data loader.
docs/web/sql/dql/select.mdx
+2 -2
View File
@@ -107,8 +107,8 @@ A CTE is scoped to the statement. One you want to keep is a
## Subqueries {#subqueries}
Subqueries are allowed anywhere an expression or a relation is -- in `FROM`, in
`WHERE` with `IN` or `EXISTS`, and as a scalar in the select list:
Subqueries are allowed anywhere an expression or a relation is (in `FROM`, in
`WHERE` with `IN` or `EXISTS`, and as a scalar in the select list):
```sql
SELECT title
docs/web/sql/dql/window.mdx
+1 -1
View File
@@ -89,7 +89,7 @@ WITH ranked AS (
SELECT * FROM ranked WHERE rn = 1
```
The outer query is needed because a window function cannot appear in `WHERE` --
The outer query is needed because a window function cannot appear in `WHERE`:
windows are computed after filtering, so the predicate would have nothing to
read.
docs/web/sql/functions.mdx
+5 -5
View File
@@ -14,9 +14,9 @@ plus what Lance adds.
| | |
| --- | --- |
| [Scalar functions](/sql/scalar-functions) | per row — math, string, regex, date/time, array, struct, JSON |
| [Aggregate functions](/sql/dql/aggregation#functions) | per group — `count`, `sum`, statistical, approximate |
| [Window functions](/sql/dql/window#functions) | per window — ranking, offset, running aggregates |
| [Scalar functions](/sql/scalar-functions) | per row: math, string, regex, date/time, array, struct, JSON |
| [Aggregate functions](/sql/dql/aggregation#functions) | per group: `count`, `sum`, statistical, approximate |
| [Window functions](/sql/dql/window#functions) | per window: ranking, offset, running aggregates |
| [Table functions](#table-functions) | produce a relation rather than a value |
<Note>
@@ -51,7 +51,7 @@ and multi-match queries use this JSON encoding.
Its schema contains the dataset's columns plus `_score`, so every stored
column is available in the result. Projections push into the scan.
Being a relation is also what makes it compose — join it, filter it, aggregate
Being a relation is also what makes it compose: join it, filter it, aggregate
over it. This join additionally requires `my_docs.category_id` and a
`categories` table with `id` and `name` columns:
@@ -73,7 +73,7 @@ multi-match query forms.
### `_score` {#score}
A pseudo-column produced by `fts()`, carrying relevance for the row. It behaves
like any other column — order by it, filter on it, project it — and exists only
like any other column (order by it, filter on it, project it) and exists only
in a relation that came from `fts()`. See
[Data types](/sql/data-types#pseudo-columns).
docs/web/sql/index.mdx
+4 -4
View File
@@ -38,7 +38,7 @@ collecting the entire result in application memory. See
The endpoint executes one statement per request and is meant for the queries
and DDL/DML pages below. Reach for the SDKs instead for table-management
operations that have no SQL form, such as a merge insert -- see
operations that have no SQL form, such as a merge insert. See
[What SQL cannot do](#cannot).
## Reference {#reference}
@@ -66,7 +66,7 @@ Draft for the Functions release. Add this row to the table above, after Index:
| [Insert](/sql/dml/insert) | `INSERT INTO`, including `INSERT ... SELECT` |
| [Update](/sql/dml/update) | `UPDATE ... SET` |
| [Delete](/sql/dml/delete) | `DELETE FROM` |
| [Copy](/sql/dml/copy) | `COPY` -- refused by recent deployment versions |
| [Copy](/sql/dml/copy) | `COPY` (refused by recent deployment versions) |
| [Refresh](/sql/dml/refresh) | filling computed columns and materialized views |
### DQL {#dql}
@@ -97,9 +97,9 @@ Draft for the Functions release. Add this row to the table above, after Index:
| | |
| --- | --- |
| Vector search | See [SQL vector search](/basics/sql#no-vector-sql) for supported query forms and server-version requirements. The [SDK query builder](/search/vector-search) also supports vector search. |
| Merge insert | no SQL form -- needs a source relation and a per-match policy |
| Merge insert | no SQL form: it needs a source relation and a per-match policy |
| `information_schema` | not enabled, so `SHOW TABLES` and `SHOW COLUMNS` fail |
| `COPY` | refused by recent deployment versions -- see [Copy](/sql/dml/copy) |
| `COPY` | refused by recent deployment versions (see [Copy](/sql/dml/copy)) |
| `PREPARE` / `EXECUTE` | preparation is a [protocol feature](/sql/prepared-statements), not a statement |
| Run on a local database | no engine to plan the statement |
docs/web/sql/operators.mdx
+6 -6
View File
@@ -17,7 +17,7 @@ operator precedence.
| | |
| --- | --- |
| `=` `!=` `<>` `<` `<=` `>` `>=` | ordinary comparison |
| `IS NULL` / `IS NOT NULL` | null test — `= NULL` is never true |
| `IS NULL` / `IS NOT NULL` | null test (`= NULL` is never true) |
| `IS DISTINCT FROM` | comparison that treats null as a value |
| `BETWEEN a AND b` | inclusive range |
| `IN (...)` | set membership |
@@ -34,7 +34,7 @@ its wildcard semantics.
`AND`, `OR`, `NOT`. Three-valued: a comparison against null is **unknown**, and
`NOT unknown` is still unknown. A `WHERE` clause keeps only rows where the
predicate is true, so unknown behaves like false there — but not inside `NOT
predicate is true, so unknown behaves like false there, but not inside `NOT
IN`, which is the usual place this bites. See
[Subqueries](/sql/dql/subqueries#in-exists).
@@ -43,7 +43,7 @@ IN`, which is the usual place this bites. See
`+` `-` `*` `/` `%`, with the usual precedence. String concatenation is `||`.
<Warning>
Arithmetic over a vector column is **list** arithmetic, not scalar arithmetic —
Arithmetic over a vector column is **list** arithmetic, not scalar arithmetic:
a vector is a `FixedSizeList<Float32>`. When the operation you want is a
similarity comparison, use [vector search](/search/vector-search); whether SQL
can express it [depends on the Enterprise server version](/basics/sql#no-vector-sql).
@@ -53,7 +53,7 @@ can express it [depends on the Enterprise server version](/basics/sql#no-vector-
| | |
| --- | --- |
| String | `'text'` — doubled quote to escape: `'it''s'` |
| String | `'text'`, with a doubled quote to escape: `'it''s'` |
| Number | `42`, `3.14` |
| Boolean | `TRUE`, `FALSE` |
| Null | `NULL` |
@@ -61,8 +61,8 @@ can express it [depends on the Enterprise server version](/basics/sql#no-vector-
| Interval | `INTERVAL '7 days'` |
| Array | `[1, 2, 3]` |
Identifiers are quoted with double quotes when they need to be — a reserved word
or a name with mixed case: `SELECT "order" FROM "MyTable"`.
Identifiers are quoted with double quotes when they need to be (a reserved word
or a name with mixed case): `SELECT "order" FROM "MyTable"`.
## Casting {#casting}
docs/web/sql/scalar-functions.mdx
+1 -1
View File
@@ -143,7 +143,7 @@ punctuation. Equivalent to an `fts()` match query with fuzziness off, `AND`
semantics and the simple tokenizer.
**Index-accelerated.** When the column has a full-text index that suits the
query, the planner uses it instead of scanning — which is the reason to prefer
query, the planner uses it instead of scanning, which is the reason to prefer
it over `LIKE` for keyword tests.
### JSON accessors {#json}