mirror of
https://github.com/lancedb/lancedb.git
synced 2026-11-13 14:16:54 +00:00
A broad documentation pass across the areas LanceDB Enterprise and Embedded diverge on most: **Data Curation** -- GPU Function execution, Slurm scheduling (and what Slurm is, for readers new to it), blob late materialization as its own page, joins, aggregation/profiling, sampling, near-duplicate detection, chunking, distributed shuffle, and IVF-partition clustering. **Feature Engineering** -- computed columns and materialized views, restructured to lead with the Function-based path and show the SQL form side by side with Python throughout; a single Auto Refresh page instead of duplicating scheduling details on every refresh page; adaptive execution; checkpointing; GPU and Slurm placement for refresh workers; a Training Cache page for the PyTorch data loader's automatic cache benefit. **Security & Governance** -- an Audit Log reference (schema, access, grants), Secrets promoted to an ordinary catalog object with their own SQL DDL and a vending/rotation guide, and privilege-table fixes verified against the authorization source. **Deployment & Maintenance** -- Horizontal Scaling and OpenTelemetry moved into a real Deployment area; Automated Cleanup folded into Intelligent Auto-Maintenance (every other maintenance decision already lived there); RTE Compaction and Advanced Conflict Resolution documented in depth. **Landing page** -- the Enterprise feature comparison table reorganized (several redundant or stale rows removed, several new areas added), and the "why Enterprise" bullets replaced with ones tied to a concrete page (Performance, Scale, Fault tolerance, Multicloud deployment, Simplify operations) instead of vague promises. Plus a full pass addressing lancedb-gatekeeper's review: a real test-safety bug (a quickstart test could silently overwrite and delete a deployment's own `frames` table), a fabricated SQL statement with no backing implementation, an actual dedup-guarantee bug in `take_row_ids`, and dozens of documentation-accuracy fixes verified against source rather than taken on faith -- each either fixed, or left with an explicit note on why it needs a feature or deployment owner's sign-off instead of being guessed at. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018PXMCbRH6i5w47TsjeEUMT --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
142 lines
6.1 KiB
Plaintext
142 lines
6.1 KiB
Plaintext
---
|
|
title: "Grant"
|
|
sidebarTitle: "Grant"
|
|
description: "GRANT and REVOKE: privileges on every catalog object, from a database down to a Function."
|
|
icon: user-lock
|
|
keywords: ["grant", "revoke", "privileges", "authorization", "sql", "ownership"]
|
|
availability:
|
|
embedded: unavailable
|
|
enterprise: available
|
|
---
|
|
|
|
<CodeGroup>
|
|
```sql SQL icon="database"
|
|
GRANT <privilege>[, <privilege>...] ON <target> TO <grantee>[, <grantee>...]
|
|
REVOKE <privilege>[, <privilege>...] ON <target> FROM <grantee>[, <grantee>...]
|
|
|
|
<target> ::= SYSTEM | DATABASE <name> | SCHEMA <namespace> | NAMESPACE <name> [IN <schema>] | TABLE <name> | VIEW <name>
|
|
| MATERIALIZED VIEW <name> | SECRET <name> | STORAGE INTEGRATION <name> | FUNCTION <name>
|
|
<grantee> ::= [ROLE] <role> | [USER] { <name> | ID '<id>' } | [GROUP] { <name> | ID '<id>' }
|
|
```
|
|
</CodeGroup>
|
|
|
|
<CodeGroup>
|
|
```sql SQL icon="database"
|
|
GRANT OPERATE, USAGE ON SYSTEM TO ROLE ops
|
|
GRANT USAGE, CREATE SCHEMA ON DATABASE analytics TO ROLE readers
|
|
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE events TO ROLE etl
|
|
GRANT CREATE SECRET, CREATE FUNCTION ON SCHEMA platform TO ROLE platform_admins
|
|
GRANT USAGE, UPDATE ON SECRET platform.`openai-prod` TO ROLE etl, rotation_service
|
|
GRANT USAGE ON SECRET platform.`openai-prod` TO USER alice, GROUP ID 'g1'
|
|
GRANT USAGE ON FUNCTION platform.embed TO ROLE research
|
|
GRANT OWNERSHIP ON SECRET platform.`openai-prod` TO ROLE platform_admins
|
|
REVOKE USAGE ON FUNCTION platform.embed FROM ROLE research
|
|
```
|
|
</CodeGroup>
|
|
|
|
## Privileges {#privileges}
|
|
|
|
| Target | Privileges it accepts |
|
|
| --- | --- |
|
|
| `SYSTEM` | `OPERATE`, `CREATE DATABASE`, `USAGE` -- no `OWNERSHIP`; the system itself has no owner |
|
|
| `DATABASE` | `OWNERSHIP`, `USAGE`, `CREATE SCHEMA` (or `CREATE NAMESPACE`) |
|
|
| `SCHEMA` (a namespace) | `OWNERSHIP`, `USAGE`, `CREATE NAMESPACE`, `CREATE TABLE`, `CREATE MATERIALIZED VIEW`, `CREATE VIEW`, `CREATE SECRET`, `CREATE STORAGE INTEGRATION`, `CREATE FUNCTION` |
|
|
| `TABLE`, `MATERIALIZED VIEW` | `OWNERSHIP`, `SELECT`, `INSERT`, `UPDATE`, `DELETE` |
|
|
| `VIEW` | `OWNERSHIP`, `SELECT` |
|
|
| `SECRET` | `OWNERSHIP`, `USAGE` (bind it to a Function), `UPDATE` (rotate it) |
|
|
| `STORAGE INTEGRATION` | `OWNERSHIP`, `USAGE` |
|
|
| `FUNCTION` | `OWNERSHIP`, `USAGE` (call it in a query, bind it to a column, or refresh a column it computes) |
|
|
|
|
<Warning>
|
|
`OWNERSHIP` cannot be revoked, only granted to someone else, which transfers
|
|
it: an object always has exactly one owner. `GRANT OWNERSHIP` is refused with
|
|
more than one grantee for the same reason.
|
|
</Warning>
|
|
|
|
See [Privileges](/governance/privileges) for what each privilege allows in
|
|
full, and how a creation privilege resolves against an object's parent when
|
|
the object doesn't exist yet.
|
|
|
|
## Grantees {#grantees}
|
|
|
|
A grantee is a role, or a user or group named by its identity-directory name
|
|
or its directory ID. A grantee with no leading `ROLE`/`USER`/`GROUP` keyword
|
|
takes the kind of the one before it, so `TO ROLE a, b` names two roles --
|
|
but the first grantee in the list always needs its keyword. An unquoted name
|
|
is folded to lowercase before it is looked up; quote one that has capitals,
|
|
such as `TO ROLE "DataEng"`.
|
|
|
|
## Naming the target {#targets}
|
|
|
|
A `SECRET` or `FUNCTION` target can be qualified with its namespace and
|
|
database, the same as anywhere else: `SECRET analytics.api_key`,
|
|
`SECRET db1.analytics.api_key`. `SCHEMA` and `NAMESPACE` both target a
|
|
namespace but aren't interchangeable: `SCHEMA <namespace>` takes the
|
|
namespace's complete path, while `NAMESPACE <name> [IN <schema>]` takes
|
|
one unqualified component, resolved under an explicit parent schema or the
|
|
session's current namespace when `IN` is omitted -- `NAMESPACE a.b` (a
|
|
qualified name with no `IN`) is refused. A `MATERIALIZED VIEW` is a table
|
|
for authorization purposes: the same privileges apply, and granting one
|
|
does not reach the non-materialized `VIEW` beside it.
|
|
|
|
## How a statement is applied {#semantics}
|
|
|
|
- A statement applies all of its changes or none of them.
|
|
- The caller must already hold `OWNERSHIP` on the object to change any grant
|
|
on it.
|
|
- Granting a privilege a grantee already holds, or revoking one it does not
|
|
hold, is a no-op.
|
|
- `GRANT` requires the object to exist; `REVOKE` does not, so an entry left
|
|
on a dropped object can still be removed. A role need not exist
|
|
beforehand, but a `USER` or `GROUP` name must resolve to exactly one
|
|
identity in your identity provider -- checked only after the caller's
|
|
`OWNERSHIP` -- or the statement fails. The `ID '<id>'` form is not looked
|
|
up.
|
|
- `GRANT ... ON ... FROM ...` and `REVOKE ... ON ... TO ...` are both
|
|
refused; `GRANT` always takes `TO`, `REVOKE` always takes `FROM`.
|
|
- Returns one row per privilege and grantee, with status `granted`,
|
|
`already_granted`, `revoked` or `not_granted`.
|
|
|
|
<Note>
|
|
SQL has no syntax for binding a Secret to a Function; that's a
|
|
registration-time argument to `create_function` in the Python SDK. See
|
|
[Vend a Secret to a Function](/curation/vend-secret).
|
|
</Note>
|
|
|
|
## SHOW GRANTS {#show-grants}
|
|
|
|
<CodeGroup>
|
|
```sql SQL icon="database"
|
|
SHOW GRANTS [ON <target>] [TO <grantee>[, <grantee>...]] [LIMIT n]
|
|
```
|
|
</CodeGroup>
|
|
|
|
<CodeGroup>
|
|
```sql SQL icon="database"
|
|
SHOW GRANTS
|
|
SHOW GRANTS ON TABLE events TO ROLE readers LIMIT 2
|
|
SHOW GRANTS ON NAMESPACE features IN analytics.team
|
|
SHOW GRANTS TO USER ID 'p1'
|
|
```
|
|
</CodeGroup>
|
|
|
|
Lists grants as rows of `subject_id`, `subject_name`, `object` and
|
|
`privilege`. `ON` filters to one target's own grants; `TO` filters to one
|
|
or more grantees; combine both, or omit both for every grant the caller
|
|
can see. `ON <target>` requires `USAGE` on that target; a target-less call
|
|
requires system `USAGE` instead, since it can surface grants across the
|
|
whole catalog. `SHOW ROLE BINDINGS` is the counterpart for role
|
|
membership rather than object privileges -- see
|
|
[Role membership in SQL](/governance/principals#membership).
|
|
|
|
## What to read next {#next}
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Privileges" icon="key" href="/governance/privileges">
|
|
The full privilege model, and how creation privileges resolve upward.
|
|
</Card>
|
|
<Card title="Namespace" icon="folder-tree" href="/sql/ddl/namespace">
|
|
Creating the schemas these privileges apply to.
|
|
</Card>
|
|
</CardGroup>
|