Support CREATE VECTOR INDEX

[moshap-firebolt]

CREATE VECTOR INDEX creates an index for approximate nearest-neighbor search over an embedding column. It is not specific to one dialect — BigQuery, Oracle, SQL Server, MariaDB and TiDB all have it (so the Generic dialect should too). VECTOR is not a keyword, so parse_create previously failed with Expected: an object type after CREATE, found: VECTOR.

The statement shares a common core across dialects and then diverges into dialect-specific trailers. It is parsed permissively for every dialect.

Common core

CREATE [OR REPLACE] VECTOR INDEX [IF NOT EXISTS] <name> ON <table>(<column | expr>)

VECTOR is treated as a modifier on CREATE INDEX (like UNIQUE), reusing the existing CreateIndex node rather than a new statement variant. It is routed through parse_create_index, so it inherits the standard index trailers — USING <method>, INCLUDE (...), WITH (...), expression targets and index options.

Per-dialect forms

Dialect	Form / trailer	Status
BigQuery	OPTIONS(index_type=…, distance_type=…, ivf_options='{…}'), STORING(col, …)	parsed
SQL Server	WITH (METRIC=…, TYPE=…, MAXDOP=…), bracket-quoted names	parsed
TiDB	expression target ((VEC_COSINE_DISTANCE(col))), trailing USING HNSW	parsed
Oracle	core, expression target, INCLUDE (...)	parsed
Oracle	ORGANIZATION …, DISTANCE …, WITH TARGET ACCURACY …, PARAMETERS(...)	not yet — follow-up
MariaDB	bare DISTANCE = … M = … options	not yet — follow-up

The two follow-up rows need dedicated grammar with real keyword-collision hazards — WITH TARGET ACCURACY overloads the same WITH keyword as SQL Server's WITH (...), and MariaDB's bare single-letter M collides with identifiers — so they are left out of this change.

Changes

• Add vector, or_replace, options and storing fields to CreateIndex. Display renders CREATE [OR REPLACE ]VECTOR INDEX … and the STORING(...) / OPTIONS(...) trailers.
• Accept a WITH (...) clause on a vector index in every dialect (for SQL Server), not only the dialects that enable it for a plain CREATE INDEX.
• Plain CREATE INDEX is unchanged (the new fields default to false/empty).

Tests

All are round-trip (verified_stmt) tests.

• tests/sqlparser_common.rs — the generic core plus the shared trailers (INCLUDE, STORING, WITH, USING, expression targets), across all dialects.
• tests/sqlparser_bigquery.rs — OPTIONS(...) with real index_type / distance_type / JSON keys, and STORING(...).
• tests/sqlparser_mssql.rs — bracket-quoted names with WITH (...).
• tests/sqlparser_mysql.rs — TiDB's distance-function target with USING.
• tests/sqlparser_oracle.rs — the core, an expression target and an INCLUDE list.

Docs: BigQuery · Oracle · SQL Server · MariaDB · TiDB

[LucaCappelletti94]

At this time, this PR edits would suggest that CREATE VECTOR INDEX is a BigQuery-specific syntax, but it is not, as it is supported also by:

• Oracle SQL
• Microsoft SQL
• Therefore also Generic Dialect

Therefore, move the tests to sqlparser common and ensure that all dialects that support the syntax successfully parse it. It may be acceptable to maintainers that dialects that do not support the syntax also parse it given the current preference for permissive parsing. I suggest you also review the possible syntax variations that these other dialects may have on this syntax, so as to cover more of its variants completely.

[moshap-firebolt]

@LucaCappelletti94 - done, added tests demonstrating different syntaxes. Note - didn't implement full blown Oracle's one.