feat: use SQL for remote view lifecycle

Stacked on #4675.

Remote view create, describe, list, and drop now execute SQL. CREATE returns the stored definition, resolution defaults, and Arrow schema from the same execution; DESCRIBE VIEW returns that metadata and SHOW VIEWS supports scoped pagination.

`drop_view_async()` returns a `job_type="query"` handle whose single `job.id` is the SQL query UUID. Waiting drains the query result once and caches completion; `describe_query(job.id)` works on the submitting connection. Completion means catalog removal, with physical cleanup continuing separately. Query handles have no registry history and cannot be reopened through `open_job()`.
This commit is contained in:
Jack Ye
2026-10-31 02:09:54 +08:00
committed by GitHub
parent 45e00d4de7
commit ac7930fa77
13 changed files with 477 additions and 562 deletions
+21 -5
View File
@@ -1,7 +1,7 @@
---
title: "View"
sidebarTitle: "View"
description: "CREATE VIEW and DROP VIEW: a saved query, evaluated when read."
description: "Create, describe, list, and drop saved queries with SQL."
icon: eye
keywords: ["create view", "drop view", "sql", "catalog"]
availability:
@@ -16,8 +16,10 @@ 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
that query runs.
There is no SDK method for a view, because the thing it stores *is* a SQL
statement.
The SDK methods `create_view`, `describe_view`, `list_views`, and `drop_view`
submit SQL through the connection's Flight endpoint. `drop_view_async` returns
a job of type `query` whose single `id` is the SQL query UUID. Waiting confirms
catalog removal; physical cleanup can continue afterward.
## CREATE VIEW {#create}
@@ -28,8 +30,10 @@ 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 one UTF-8 `definition` column containing JSON with the
view name, namespace, original query, default database and namespace, and its
Arrow schema resolved at creation time. `DESCRIBE VIEW "recent_matches"`
returns the same metadata shape. Anything the
[dialect](/sql/functions) supports can define one: joins, predicates,
aggregates, window functions.
@@ -56,6 +60,18 @@ was none to begin with.
## Listing {#listing}
```sql
SHOW VIEWS
SHOW VIEWS IN "analytics" WHERE name > 'previous_view' LIMIT 100
```
`SHOW VIEWS` returns ascending `name` values and a nullable `location` column.
Locations are populated only when the deployment exposes catalog locations.
The `name` cursor is scoped to the selected namespace.
Object commands retain their small results in shared storage even when general
query-result copying is disabled, so asynchronous polling can use any query node.
Views and tables share a namespace, and both are things you can query. The
catalog distinguishes them: