mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-16 16:52:34 +00:00
Brendan Clement
06aa526ae1
This PR is part of the documentation revamp. Once the full set of PRs is merged, we’ll publish the combined site to staging for review before updating docs.lancedb.com. The curation, SQL and operations pages contain outdated claims and examples that do not reliably work as written. This corrects those pages against the reviewed SDK and local server evidence, including prepared statements, background jobs, cleanup and monitoring. Integration guides are grouped with their examples in #4533. Function and Secret-object documentation stays unpublished until its release. The two Function pages are listed in `.mintignore` and left out of the navigation, and the sections about them on other pages are MDX comments. Stacked on #4533. Each MDX file has one PR owner. Rebase onto main after #4533 is squash-merged. Local assembly, Mint validation and link checks pass, and the assembled site shows no Function or Secret-object content. A local release rehearsal that uncomments the drafts and restores the navigation also passes. Hold publication until this PR and lancedb/sophon#8688 are on `main`.
62 lines
2.3 KiB
Plaintext
62 lines
2.3 KiB
Plaintext
---
|
|
title: "Prepared statements"
|
|
sidebarTitle: "Prepared Statements"
|
|
description: "What a deployment does when a Flight SQL client prepares a statement or binds parameter values."
|
|
icon: bolt
|
|
keywords: ["prepared statement", "flight sql", "parameters", "bind"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)
|
|
|
|
A Flight SQL client can prepare a statement before it runs it. A deployment
|
|
accepts that, but it keeps no plan between runs and does not accept parameter
|
|
values.
|
|
|
|
## Prepare through a Flight SQL client {#protocol}
|
|
|
|
<Warning>
|
|
There is no SQL `PREPARE` / `EXECUTE` here. Preparation is part of the
|
|
**Arrow Flight SQL protocol**, so you reach it through your client rather than
|
|
by sending a statement.
|
|
</Warning>
|
|
|
|
That distinction matters when porting SQL from another engine: a script
|
|
containing `PREPARE name AS SELECT ...` will not run.
|
|
|
|
## Prepare and execute {#flow}
|
|
|
|
A Flight SQL client takes these steps, whatever it calls them:
|
|
|
|
1. **Prepare:** send the SQL and get back a handle and the result schema. The
|
|
statement is parsed and planned at this point, so a syntax or name error
|
|
surfaces here rather than at execution.
|
|
2. **Execute:** run the handle and read the result. The deployment plans the
|
|
statement again each time it runs, so reusing a handle does not save
|
|
planning time.
|
|
3. **Close:** release the handle.
|
|
|
|
## Parameters {#parameters}
|
|
|
|
A deployment does not accept parameter values for a prepared statement. A
|
|
client that binds values to placeholders such as `$1` and `$2` gets a "not
|
|
implemented" error when it executes the statement. A statement with fixed,
|
|
trusted values written into it runs as usual:
|
|
|
|
```sql
|
|
SELECT id, title FROM documents WHERE category = 'news' AND score > 0.5
|
|
```
|
|
|
|
Do not put untrusted input, such as a value from a user or a request, directly
|
|
into the statement text. Quoting it does not protect the statement the way
|
|
binding a parameter would.
|
|
|
|
## When to use prepared statements {#when}
|
|
|
|
Prepare a statement when your client requires it, or to get a statement's
|
|
result schema and catch syntax and name errors without running it. Preparing
|
|
does not make a repeated statement faster.
|
|
|
|
To give a reusable query a name, create a [view](/management/view). To store
|
|
its result for later queries, create a
|
|
[materialized view](/management/materialized-view).
|