You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several dialects create a vector index for approximate nearest-neighbor search
over an embedding column with a `CREATE VECTOR INDEX` statement — BigQuery,
Oracle, SQL Server, MariaDB and TiDB. `VECTOR` is not a keyword, so
`parse_create` previously failed with
`Expected: an object type after CREATE, found: VECTOR`.
The common core is `CREATE [OR REPLACE] VECTOR INDEX [IF NOT EXISTS] <name> ON
<table>(<column | expr>)`, after which dialects add different trailers
(BigQuery `OPTIONS(...)`, SQL Server `WITH (...)`, Oracle `INCLUDE`/bare
clauses, TiDB `USING`). It is parsed permissively for every dialect.
### Changes
- Add `vector`, `or_replace` and `options` fields to `CreateIndex`. `VECTOR` is
a modifier on `CREATE INDEX` (like `UNIQUE`), so it reuses the existing node
rather than a new statement variant. `Display` renders
`CREATE [OR REPLACE ]VECTOR INDEX ...` and the `OPTIONS(...)` trailer.
- Route `CREATE VECTOR INDEX` through `parse_create_index`, so it inherits the
existing index trailers — `USING`, `INCLUDE`, `WITH`, expression targets and
index options — that cover the Oracle / SQL Server / TiDB variants. The
BigQuery `OPTIONS(...)` clause reuses `parse_options` / `SqlOption`, parsing
and rendering like `CREATE TABLE` / `CREATE VIEW` OPTIONS.
- Plain `CREATE INDEX` is unchanged (the three fields default to false/empty).
- Test `parse_create_vector_index` in `tests/sqlparser_common.rs` verifies the
round-trip across all dialects and covers `OR REPLACE`, `IF NOT EXISTS`,
schema-qualified names, `OPTIONS(...)` and the shared `INCLUDE` trailer.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments