pub struct IndexAlterSyntax {Show 21 fields
pub rename_constraint: bool,
pub alter_table_set_options: bool,
pub drop_primary_key: bool,
pub alter_column_add_identity: bool,
pub index_storage_parameters: bool,
pub drop_behavior: bool,
pub index_drop_on_table: bool,
pub index_concurrently: bool,
pub index_using_method: bool,
pub partial_index: bool,
pub index_if_not_exists: bool,
pub index_nulls_order: bool,
pub alter_table_extended: bool,
pub alter_table_multiple_actions: bool,
pub alter_existence_guards: bool,
pub alter_nested_column_paths: bool,
pub alter_column_set_data_type: bool,
pub routine_arg_types: bool,
pub routine_arg_defaults: bool,
pub routine_arg_modes: bool,
pub routine_language_string: bool,
}Expand description
Dialect-owned CREATE INDEX / ALTER TABLE / DROP syntax accepted by the parser.
The clause-level gates on the index, alter-table, and drop statements — the object-DDL
surface that decorates an already-dispatched statement rather than deciding its leading
keyword. Split out of the retired SchemaChangeSyntax at its 16-field line as the
index/alter/drop axis, distinct from the whole-statement-dispatch axis. Each flag is a
grammar gate: when off the keyword is left unconsumed and rejects.
Fields§
§rename_constraint: boolAccept PostgreSQL ALTER TABLE … RENAME CONSTRAINT <old> TO <new>.
alter_table_set_options: boolAccept ALTER TABLE … SET (<name> = <value>, …) table options.
drop_primary_key: boolAccept the unnamed ALTER TABLE … DROP PRIMARY KEY action.
alter_column_add_identity: boolAccept ALTER TABLE … ALTER COLUMN <name> ADD GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY [(…)].
index_storage_parameters: boolAccept CREATE INDEX … (<keys>) WITH (<name> = <value>, …) storage parameters.
drop_behavior: boolAccept a trailing CASCADE / RESTRICT drop behaviour on DROP statements
and ALTER TABLE ... DROP actions (the SQL standard <drop behavior>;
PostgreSQL). A dialect that does not model dependency behaviour leaves it off.
index_drop_on_table: boolAccept MySQL’s DROP INDEX <name> ON <table> [ALGORITHM [=] {DEFAULT | INPLACE | INSTANT | COPY}] [LOCK [=] {DEFAULT | NONE | SHARED | EXCLUSIVE}] — the index drop
that names its owning table with a mandatory ON and carries the online-DDL
ALGORITHM/LOCK execution hints (drop_index_stmt/opt_index_lock_and_algorithm,
sql_yacc.yy). Server-measured on mysql:8: the ON <table> is mandatory (DROP INDEX i with no ON is ER_PARSE_ERROR), the tail admits at most one ALGORITHM and one
LOCK in either order, and no trailing CASCADE/RESTRICT. On for MySQL only. Off
elsewhere, where DROP INDEX <name> [, …] stays the shared name-list drop; enabling it
would make the mandatory-ON form displace that name-list drop, so Lenient forgoes it
to keep the more permissive bare-name form (a documented conflict resolution). With the
flag off a DROP INDEX i ON t leaves ON unconsumed and surfaces as a clean parse
error.
index_concurrently: boolAccept CREATE INDEX CONCURRENTLY (PostgreSQL builds the index without an
exclusive table lock). Not ANSI.
index_using_method: boolAccept the CREATE INDEX … USING <method> access-method clause (PostgreSQL
btree/hash/gin/gist/…; MySQL USING BTREE). Not ANSI.
partial_index: boolAccept a trailing WHERE <predicate> partial-index clause on CREATE INDEX
(PostgreSQL, SQLite). Not ANSI.
index_if_not_exists: boolAccept the IF NOT EXISTS guard on CREATE INDEX (PostgreSQL/SQLite/DuckDB). On for
ANSI/PostgreSQL/SQLite/DuckDB/Lenient. MySQL has no CREATE INDEX IF NOT EXISTS
(engine-measured ER_PARSE_ERROR on mysql:8), so it is off; the IF NOT EXISTS is
then left unconsumed and the following index name surfaces as a clean parse error.
Distinct from the CREATE TABLE/CREATE DATABASE guards, which MySQL does admit.
index_nulls_order: boolAccept the per-key NULLS FIRST / NULLS LAST null-ordering modifier on a
CREATE INDEX column (PostgreSQL/SQLite 3.30+). On for ANSI/PostgreSQL/SQLite/DuckDB/
Lenient. MySQL has no index-key NULLS ordering (engine-measured ER_PARSE_ERROR on
mysql:8; it orders NULLs implicitly), so it is off; the NULLS keyword is then left
unconsumed and surfaces as a clean parse error. Independent of the ORDER BY null
ordering, which is a separate grammar position.
alter_table_extended: boolAccept the extended ALTER TABLE surface beyond SQLite’s lenient action set: the
table-level IF EXISTS, comma-separated multiple actions, ALTER COLUMN …, the
ADD PRIMARY KEY/UNIQUE/FOREIGN KEY table constraints, and the IF [NOT] EXISTS guard on ADD/DROP COLUMN (PostgreSQL/MySQL). On for ANSI/PostgreSQL/
MySQL/DuckDB/Lenient. Off for SQLite, whose ALTER TABLE (engine-measured via
rusqlite) admits RENAME TO/RENAME COLUMN, a single ADD [COLUMN] <def> / ADD [CONSTRAINT …] CHECK (…), and a single DROP [COLUMN] / DROP CONSTRAINT — those
stay accepted with the flag off; every other form is left unconsumed and surfaces
as a clean parse error. Distinct from ExistenceGuards::if_exists, which stays
on for SQLite (its DROP TABLE IF EXISTS is valid) — only the ALTER existence
guard is gated here.
alter_table_multiple_actions: boolAccept a comma-separated multi-action ALTER TABLE list
(ALTER TABLE t ADD COLUMN a INT, DROP COLUMN b). On for ANSI/PostgreSQL/MySQL/Lenient.
Off for DuckDB (parse-rejects with “Only one ALTER command per statement is supported”,
probed on 1.5.4) and moot for SQLite (its
alter_table_extended is already off, so the
multi-action loop is never entered). Only reachable where alter_table_extended is on;
with the flag off the first action parses and a trailing comma surfaces as a clean parse
error.
alter_existence_guards: boolAccept an IF EXISTS / IF NOT EXISTS existence guard inside ALTER TABLE — the
table-level ALTER TABLE IF EXISTS t … and the per-action ADD COLUMN IF NOT EXISTS
/ DROP [COLUMN|CONSTRAINT] IF EXISTS guards. On for PostgreSQL/DuckDB/Lenient (and
unused by SQLite, whose non-alter_table_extended path
parses no guard, so it rides that gate —
FeatureDependencyViolation::AlterExistenceGuardsWithoutAlterTableExtended). MySQL
supports the extended ALTER TABLE surface (multi-action
lists, ADD/DROP CONSTRAINT, ALTER COLUMN) but not these guards
(ALTER TABLE IF EXISTS, ADD COLUMN IF NOT EXISTS, DROP COLUMN IF EXISTS are each
ER_PARSE_ERROR on mysql:8), so it is off there; the IF keyword is then read as a
name and surfaces as a clean parse error. Distinct from
ExistenceGuards::if_exists, which MySQL keeps on for
DROP TABLE IF EXISTS.
alter_nested_column_paths: boolAccept dotted nested-column paths in DuckDB ALTER TABLE column targets for the
actions the engine parses (ADD COLUMN s.k, DROP COLUMN s.k, and old-side
RENAME COLUMN s.k TO k2). The gate does not affect ALTER COLUMN or the rename
destination: DuckDB 1.5.4 parse-rejects dotted paths in those positions.
alter_column_set_data_type: boolAccept the PostgreSQL ALTER TABLE … ALTER COLUMN actions beyond SET/DROP DEFAULT — SET DATA TYPE <type> (and its bare TYPE <type> synonym, with an
optional USING <expr>) plus SET/DROP NOT NULL. On for PostgreSQL/DuckDB/Lenient.
MySQL’s ALTER COLUMN admits only SET/DROP DEFAULT — it changes a column’s type
with MODIFY/CHANGE — so ALTER COLUMN i SET DATA TYPE …/SET NOT NULL/DROP NOT NULL are ER_PARSE_ERROR on mysql:8; with the flag off those actions surface as a
clean parse error. SQLite never reaches the action (its
alter_table_extended is off), so this is moot there —
it rides that gate
(FeatureDependencyViolation::AlterColumnSetDataTypeWithoutAlterTableExtended).
routine_arg_types: boolAccept a routine reference’s parenthesized argument-type list — DROP FUNCTION f(INT),
GRANT EXECUTE ON FUNCTION f(INT) … (PostgreSQL overload-disambiguation). On for
ANSI/PostgreSQL/DuckDB/Lenient. MySQL identifies a routine by name alone, so the arg
list is a syntax error there (DROP FUNCTION f(INT) → engine-measured ER_PARSE_ERROR
on mysql:8); with the flag off the ( is left unconsumed and surfaces as a clean parse
error. Off for SQLite too (it has no stored routines — routines is
already off, so this is moot there).
routine_arg_defaults: boolAccept a CREATE FUNCTION parameter default — func_arg DEFAULT <expr> / func_arg = <expr> (PostgreSQL func_arg_with_default). On for ANSI/PostgreSQL/DuckDB/Lenient.
MySQL’s routine parameters are [IN|OUT|INOUT] name type with no default, so a
DEFAULT/= after the type is a syntax error there (ER_PARSE_ERROR on mysql:8); with
the flag off the DEFAULT/= is left unconsumed and the parameter-list close surfaces
as a clean parse error. Distinct from routine_arg_types
(which gates the reference-site arg-type list on DROP/GRANT): this gates the
definition-site default on CREATE FUNCTION. Off for SQLite too (no stored routines —
routines is already off, so this is moot there).
routine_arg_modes: boolAccept a CREATE FUNCTION parameter argument mode — the arg_class prefix
IN/OUT/INOUT/VARIADIC before the parameter (PostgreSQL func_arg). On for
ANSI/PostgreSQL/DuckDB/Lenient. MySQL’s CREATE FUNCTION parameters are name type
with no mode (the IN/OUT/INOUT modes are a stored-procedure form, a distinct
statement), so a mode keyword before a CREATE FUNCTION parameter is a syntax error
there; with the flag off the keyword is left for the name/type parse (a reserved mode
keyword like IN/VARIADIC then surfaces as a clean parse error). A sibling of
routine_arg_defaults: both gate independent
definition-site CREATE FUNCTION parameter facets that MySQL’s grammar omits. Off
for SQLite too (no stored routines — routines is
already off, so this is moot there).
routine_language_string: boolAccept a string-constant (Sconst) spelling of the routine LANGUAGE name —
LANGUAGE 'sql'/E'sql'/$$sql$$ — alongside the bare word, PostgreSQL’s
NonReservedWord_or_Sconst operand (the same shape the DO … LANGUAGE argument
spells). On for PostgreSQL/Lenient. MySQL’s routine LANGUAGE admits only the bare
word SQL — LANGUAGE 'SQL' is engine-measured ER_PARSE_ERROR (1064) on mysql:8 for
both CREATE FUNCTION and CREATE PROCEDURE — so off there; with the flag off a string
in the LANGUAGE position falls through to the bare-word parse, which rejects the string
as MySQL does. Off for ANSI too: the SQL-standard <language name> is a bare identifier
(SQL/C/ADA/…), not a string. A bit-string (b'…'/x'…') or national (N'…')
constant is never an Sconst, so it stays a reject even where the flag is on (matching
PostgreSQL). Off for SQLite too (no stored routines — routines
is already off, so this is moot there).
Implementations§
Trait Implementations§
Source§impl Clone for IndexAlterSyntax
impl Clone for IndexAlterSyntax
Source§fn clone(&self) -> IndexAlterSyntax
fn clone(&self) -> IndexAlterSyntax
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more