Struct UtilitySyntax 

pub struct UtilitySyntax {

    pub copy: bool,
    pub copy_into: bool,
    pub stage_references: bool,
    pub comment_on: bool,
    pub comment_if_exists: bool,
    pub pragma: bool,
    pub attach: bool,
    pub kill: bool,
    pub handler_statements: bool,
    pub plugin_component_statements: bool,
    pub shutdown: bool,
    pub restart: bool,
    pub clone: bool,
    pub import_table: bool,
    pub help_statement: bool,
    pub binlog: bool,
    pub key_cache_statements: bool,
    pub use_statement: bool,
    pub use_qualified_name: bool,
    pub use_string_literal_name: bool,
    pub prepared_statements: bool,
    pub prepare_typed_parameters: bool,
    pub prepared_statements_from: bool,
    pub call: bool,
    pub call_bare_name: bool,
    pub load_extension: bool,
    pub load_bare_name: bool,
    pub load_data: bool,
    pub reset_scope: bool,
    pub detach_if_exists: bool,
    pub do_statement: bool,
    pub do_expression_list: bool,
    pub lock_tables: bool,
    pub lock_instance: bool,
    pub rename_statement: bool,
    pub signal_diagnostics: bool,
    pub export_import_database: bool,
    pub update_extensions: bool,
    pub flush: bool,
    pub purge_binary_logs: bool,
    pub replication_statements: bool,
}

Dialect-owned utility-statement syntax extensions accepted by the parser.

Non-TCL utility statements whose leading keyword a dialect dispatches — COPY, PRAGMA, ATTACH, prepared statements, locks, replication, … — the statement-keyword analogue of MutationSyntax::merge. Transaction-control grammar lives in TransactionSyntax. Whether each statement is dispatched is explicit dialect data: when a flag is off the keyword is left undispatched and surfaces as an unknown statement. Statement-head flags on this axis are consumed by the parser’s statement-head router (parser::statement_dispatch); parse bodies live in family modules (util, …). EXPLAIN is not gated here (accepted dialect-agnostically for now). Introspection, physical-maintenance, and access-control statements live in ShowSyntax, MaintenanceSyntax, and AccessControlSyntax.

Fields

copy: bool

Accept the PostgreSQL COPY <table>|(<query>) {FROM|TO} <endpoint> ... bulk data-transfer statement. PostgreSQL-only (also its generic/permissive supersets); off in ANSI and MySQL, which have no COPY, so there the leading COPY keyword is not dispatched and surfaces as an unknown statement.

copy_into: bool

Accept the Snowflake COPY INTO <target> FROM <source> [<opt> = <val> ...] bulk load/unload statement — a distinct grammar from the PostgreSQL COPY gated by copy: fixed INTO … FROM … direction, KEY = VALUE options with a nested FILE_FORMAT = (…) list, and the FILES/PATTERN/VALIDATION_MODE clauses. The two share only the leading COPY keyword; the dispatcher branches on the INTO that follows. On for Snowflake and Lenient; off elsewhere (including PostgreSQL and DuckDB, whose COPY is the copy-gated {FROM | TO} transfer), where a COPY INTO surfaces as an unknown statement.

stage_references: bool

Accept Snowflake stage references @stage / @~ / @%table (with optional /path segments) as a dedicated token and as a COPY INTO endpoint. On for Snowflake and Lenient; off elsewhere so @ keeps its other claimants.

comment_on: bool

Accept the PostgreSQL COMMENT ON <object> IS '<text>' | NULL object-metadata statement. PostgreSQL-only (and its permissive superset); off in ANSI and MySQL, which have no COMMENT ON, so there the leading COMMENT keyword is not dispatched and surfaces as an unknown statement.

comment_if_exists: bool

Accept the front-position COMMENT IF EXISTS ON ... guard.

pragma: bool

Accept the SQLite PRAGMA [<schema> .] <name> [= <value> | (<value>)] configuration statement. SQLite-only (and the permissive superset); off in ANSI, PostgreSQL, and MySQL, which have no PRAGMA, so there the leading PRAGMA keyword is not dispatched and surfaces as an unknown statement.

attach: bool

Accept the SQLite ATTACH [DATABASE] <expr> AS <schema> statement and its DETACH [DATABASE] <schema> inverse. One flag gates both leading keywords because they are a single dialect unit — a dialect with ATTACH has DETACH (mirroring how existence_guards.if_exists gates its paired grammar points together). SQLite-only (and the permissive superset); off in ANSI, PostgreSQL, and MySQL, so there the leading keywords are not dispatched and surface as unknown statements.

kill: bool

Accept the MySQL KILL [CONNECTION | QUERY] <id> thread/query-termination statement. MySQL-only (and the permissive superset); off in ANSI, PostgreSQL, and SQLite, which have no KILL, so there the leading keyword is not dispatched and surfaces as an unknown statement — the copy/comment_on leading-keyword-gate precedent.

handler_statements: bool

Accept the MySQL HANDLER low-level cursor family — HANDLER <t> OPEN [[AS] alias], HANDLER <t> READ …, and HANDLER <t> CLOSE — direct index-level storage-engine access that bypasses the optimizer. One flag gates the leading HANDLER keyword (all three verbs follow the opened table) — the copy/kill leading-keyword-gate precedent. MySQL-only among the shipped presets, and a pure addition in the permissive superset (the leading HANDLER collides with no other statement); off in ANSI, PostgreSQL, and SQLite, which have no HANDLER, so there it is not dispatched and surfaces as an unknown statement. See HandlerStatement.

plugin_component_statements: bool

Accept the MySQL plugin/component install-management family — INSTALL PLUGIN <name> SONAME <lib>, INSTALL COMPONENT <urn> … [SET …], UNINSTALL PLUGIN <name>, and UNINSTALL COMPONENT <urn> …. One flag gates the leading INSTALL and UNINSTALL keywords together, an install/uninstall pair kept as one dialect unit like attach/detach. MySQL-only among the shipped presets, and a pure addition in the permissive superset (the leading INSTALL/UNINSTALL collide with no other statement); off in ANSI, PostgreSQL, and SQLite, which have neither, so there they are not dispatched and surface as an unknown statement. See InstallStatement and UninstallStatement.

shutdown: bool

Accept the MySQL SHUTDOWN server-shutdown statement — a nullary leading keyword. A leading-keyword gate like kill; MySQL-only among the shipped presets and a pure addition in the permissive superset (the leading SHUTDOWN collides with no other statement); off in ANSI, PostgreSQL, and SQLite, where it is not dispatched and surfaces as an unknown statement. Separate from restart: SHUTDOWN and RESTART are distinct statements, not an inverse pair, so each takes its own flag (the vacuum/reindex precedent). See Statement::Shutdown.

restart: bool

Accept the MySQL RESTART server-restart statement — a nullary leading keyword. A leading-keyword gate like kill; MySQL-only among the shipped presets and a pure addition in the permissive superset; off in ANSI, PostgreSQL, and SQLite, where it surfaces as an unknown statement. Separate from shutdown — distinct behaviours, distinct flags. See Statement::Restart.

clone: bool

Accept the MySQL CLONE data-directory provisioning statement — CLONE LOCAL DATA DIRECTORY [=] '<dir>' and CLONE INSTANCE FROM <user>[@<host>]:<port> IDENTIFIED BY '<pw>' [DATA DIRECTORY [=] '<dir>'] [REQUIRE [NO] SSL]. One flag gates the leading CLONE keyword (both LOCAL/INSTANCE forms follow it — one statement, two forms, like flush); MySQL-only and a pure addition in the permissive superset; off in ANSI, PostgreSQL, and SQLite. See CloneStatement.

import_table: bool

Accept the MySQL IMPORT TABLE FROM '<file>' [, …] tablespace-import statement. A leading-keyword gate on IMPORT distinguished from DuckDB’s IMPORT DATABASE (export_import_database) by the second keyword (TABLE vs DATABASE): both may be on in the permissive superset without colliding. MySQL-only among the shipped presets; off in ANSI, PostgreSQL, SQLite, and DuckDB. See ImportTableStatement.

help_statement: bool

Accept the MySQL HELP '<topic>' help-lookup statement — a leading-keyword gate like kill. MySQL-only among the shipped presets and a pure addition in the permissive superset (the leading HELP collides with no other statement); off in ANSI, PostgreSQL, and SQLite. See HelpStatement.

binlog: bool

Accept the MySQL BINLOG '<base64-event>' binary-log-event replay statement — a leading-keyword gate like kill. MySQL-only among the shipped presets and a pure addition in the permissive superset; off in ANSI, PostgreSQL, and SQLite. See BinlogStatement.

key_cache_statements: bool

Accept the MySQL MyISAM key-cache statement pair — CACHE INDEX <t> [<keys>][, ...] [PARTITION (...)] IN <cache> and LOAD INDEX INTO CACHE <t> [PARTITION (...)] [<keys>] [IGNORE LEAVES][, ...]. One flag gates both leading keywords (CACHE and the LOAD INDEX lookahead) because they are a single dialect unit — key-cache assignment and preload travel together (the attach/detach, prepared_statements single-flag precedent). MySQL-only among the shipped presets, and a pure addition in the permissive superset; off in ANSI, PostgreSQL, and SQLite, where the leading keywords are not dispatched (a leading LOAD without INDEX still reaches the load_extension gate). See CacheIndexStatement and LoadIndexStatement.

use_statement: bool

Accept the USE catalog/schema-switch statement — DuckDB USE <catalog> [. <schema>] and MySQL USE <schema>. A leading-keyword gate like pragma: on for DuckDB, MySQL, and the permissive superset; off in ANSI, PostgreSQL, and SQLite, which have no USE statement, so there the leading USE keyword is not dispatched and surfaces as an unknown statement. (A non-leading USE is the MySQL index-hint keyword, consumed by the FROM grammar, so it never reaches this statement-leading position.) The accepted name arity rides use_qualified_name.

use_qualified_name: bool

Accept a dotted USE <catalog> . <schema> name (DuckDB) rather than the single unqualified USE <schema> (MySQL). Refines the name grammar of the base USE statement, so it requires use_statement: without it the leading USE is not dispatched and this flag is inert, the dependency the UseQualifiedNameWithoutUseStatement registry variant records. On for DuckDB and the permissive superset; off for MySQL, whose USE ident grammar ER_PARSE_ERRORs any dotted name (engine-measured on mysql:8), and off (vacuously) wherever use_statement is off. DuckDB still rejects a three-part USE a.b.c even with this on — that arity bound is enforced in the parser.

use_string_literal_name: bool

Accept a string-constant (Sconst) spelling of the USE target name — DuckDB’s USE 'n' / USE E'n' / USE $$n$$ single-part form (engine-measured on libduckdb 1.5.4 via duckdb_extract_statements). The string is a single-part name only: a dotted string name (USE 'a'.'b', USE a.'b') is a parser reject, matching DuckDB. Refines the name grammar of the base USE statement, so it requires use_statement: without it the leading USE is not dispatched and this flag is inert, the dependency the UseStringLiteralNameWithoutUseStatement registry variant records. On for DuckDB and the permissive superset; off for MySQL, whose USE ident grammar ER_PARSE_ERRORs a string name (engine-measured on mysql:8), and off (vacuously) wherever use_statement is off.

prepared_statements: bool

Accept the prepared-statement lifecycle: PREPARE <name> [(<types>)] AS <statement>, EXECUTE <name> [(<args>)], and DEALLOCATE [PREPARE] <name>. One flag gates the three leading keywords because they are a single dialect unit — a dialect that prepares statements executes and frees them too (the attach/detach single-flag precedent). On for DuckDB, PostgreSQL, and Lenient; off elsewhere, where the leading keywords surface as unknown statements. (EXECUTE is only a leading keyword here; the EXECUTE privilege in GRANT EXECUTE is unaffected.) The parenthesized PREPARE type list is a separate, differently-shaped surface gated by prepare_typed_parameters: this flag alone only admits the bare PREPARE <name> AS <statement> form. Never both on with MySQL’s prepared_statements_from — the pair is the registered GrammarConflict::PreparedStatementsVersusPreparedStatementsFrom.

prepare_typed_parameters: bool

Accept the PostgreSQL PREPARE name ( <type> [, ...] ) AS <statement> parenthesized parameter-type list between the name and AS — full type names (parameterized like numeric(10,2), arrayed like int[]), at least one, PostgreSQL rejects an empty (). Depends on prepared_statements being on too (the type list is a widening of that grammar’s name position, not a standalone surface); the dependency is FeatureDependencyViolation::PrepareTypedParametersWithoutPreparedStatements. On for PostgreSQL and Lenient; off for DuckDB, which structurally rejects the whole typed-parameter-list form (“Prepared statement argument types are not supported, use CAST”) — so it keeps prepared_statements for the bare form only.

prepared_statements_from: bool

Accept MySQL’s prepared-statement lifecycle: PREPARE <name> FROM {'<text>' | @<var>}, EXECUTE <name> [USING @<var>, ...], and {DEALLOCATE | DROP} PREPARE <name>. One flag gates the three leading keywords (plus the DROP PREPARE synonym) because they are a single dialect unit — the prepared_statements single-flag precedent.

A different grammar on the same three keywords from DuckDB’s typed-AS prepared_statements: MySQL prepares from a statement source (a string literal or a @-variable, never an inline-parsed statement), executes with a USING clause of @-variable references (never parenthesized expressions), and requires the PREPARE keyword after {DEALLOCATE | DROP}. The two are mutually exclusive per preset (each arms at most one), the split mirroring do_statement vs do_expression_list on the DO keyword; a preset never arms both, so the shared leading keywords dispatch unambiguously. MySQL-only among the shipped presets; off elsewhere (the permissive superset keeps the DuckDB typed-AS reading, since the FROM/USING surfaces have no positional-argument spelling). Never both on with prepared_statements — the pair is the registered GrammarConflict::PreparedStatementsVersusPreparedStatementsFrom, whose DEALLOCATE tail (mandatory PREPARE under this flag) is incoherent with the DuckDB-first dispatch of the PREPARE/EXECUTE heads. See PrepareFromStatement and ExecuteUsingStatement.

call: bool

Accept the DuckDB CALL <name>(<args>) routine/table-function invocation statement. Its own flag rather than sharing prepared_statements: CALL is an independent procedure-call statement, not part of the prepare/execute/deallocate lifecycle (the vacuum/reindex/analyze separate-flags precedent). DuckDB-only among the shipped fitted presets (and the permissive superset); off elsewhere, where a leading CALL surfaces as an unknown statement.

call_bare_name: bool

Accept MySQL’s bare CALL <name> form — a routine invocation with no parenthesized argument list at all (CALL_SYM sp_name opt_paren_expr_list, the opt_paren_expr_list %empty alternative) — on top of the base call statement (the dependency is FeatureDependencyViolation::CallBareNameWithoutCall). MySQL-only among the shipped presets (and Lenient); DuckDB’s parentheses are mandatory (a bare CALL pragma_version is a syntax error), so it is off there and a CALL name with no following ( rejects.

load_extension: bool

Accept the LOAD <string> extension/shared-library load statement. On for PostgreSQL/DuckDB/Lenient (PostgreSQL LOAD 'plpgsql', DuckDB LOAD 'tpch' — both accept a string argument); off in ANSI/MySQL/SQLite, where the leading LOAD surfaces as an unknown statement. The DuckDB bare-identifier argument rides the separate load_bare_name gate.

load_bare_name: bool

Accept DuckDB’s bare-identifier LOAD <name> argument (LOAD tpch) on top of the base load_extension statement (the dependency is FeatureDependencyViolation::LoadBareNameWithoutLoadExtension). DuckDB-only among the shipped presets (and Lenient); PostgreSQL’s LOAD requires a string (LOAD tpch is a pg_query parser error), so it is off there.

load_data: bool

Accept MySQL’s LOAD {DATA | XML} … INFILE … INTO TABLE … bulk-import statement — a DIFFERENT behaviour on the leading LOAD keyword from the PostgreSQL/DuckDB load_extension statement, dispatched on the two-word LOAD DATA/LOAD XML lookahead so the two never collide even where both gates are on (the do_statement/do_expression_list split precedent). MySQL-only among the shipped presets (and Lenient); off elsewhere, where a leading LOAD DATA surfaces as an unknown statement. Covers the classic documented clause train (PARTITION, CHARACTER SET, FIELDS/LINES, IGNORE n LINES, the column/@var list, SET, and — grammar-shared — ROWS IDENTIFIED BY); the MySQL 8.4 secondary-engine bulk-load extension clauses (URL/ S3 sources, COUNT, COMPRESSION, PARALLEL, MEMORY, ALGORITHM) are a separate feature not covered by this gate.

reset_scope: bool

Accept a SESSION | LOCAL | GLOBAL scope qualifier before a RESET <name> target (DuckDB RESET SESSION x, RESET GLOBAL x; DuckDB parse-accepts all three, though RESET LOCAL is a runtime not-implemented). DuckDB-only among the shipped presets (and Lenient); PostgreSQL’s RESET takes no scope prefix (RESET SESSION x is a pg_query parser error — its RESET SESSION AUTHORIZATION is a distinct special form, not modelled), so it is off there and a scope keyword after RESET rejects.

detach_if_exists: bool

Accept a DuckDB IF EXISTS guard on DETACH DATABASE IF EXISTS <name> (on top of the attach DETACH statement; the dependency is FeatureDependencyViolation::DetachIfExistsWithoutAttach). DuckDB-only among the shipped presets (and Lenient); DuckDB admits the guard only after the DATABASE keyword (DETACH IF EXISTS x is a parser error, DETACH DATABASE IF EXISTS x parses — probed on 1.5.4). SQLite’s DETACH has no IF EXISTS, so it is off there.

do_statement: bool

Accept the PostgreSQL DO [LANGUAGE <lang>] '<body>' anonymous code block. Its own leading-keyword gate, like copy: PostgreSQL-only among the shipped presets (and Lenient); DuckDB has no DO statement (probed on 1.5.4: DO $$...$$ is a parser error), and MySQL/SQLite have none, so there the leading DO keyword is not dispatched and surfaces as an unknown statement. The block body is an opaque procedural-language string, not re-parsed here (see DoStatement). Never both on with do_expression_list — the pair is the registered GrammarConflict::DoStatementVersusDoExpressionList.

do_expression_list: bool

Accept the MySQL DO <expr> [, <expr> ...] evaluate-and-discard statement — a different behaviour on the same DO keyword from the PostgreSQL anonymous code block gated by do_statement. The two are mutually exclusive per dialect (each preset arms at most one), the split mirroring transaction-BEGIN vs compound-block-BEGIN; a preset never arms both, so the shared leading DO keyword dispatches unambiguously. MySQL-only among the shipped presets; off elsewhere (the permissive superset keeps the PostgreSQL code-block reading, since the DO LANGUAGE form has no expression-list spelling). Enabling both at once is the registered GrammarConflict::DoStatementVersusDoExpressionList — the code-block branch shadows the expression list, so DO 'x' mis-parses and DO 1, 2 over-rejects. See DoExpressionsStatement.

lock_tables: bool

Accept the MySQL LOCK {TABLES | TABLE} <tbl> [[AS] <alias>] {READ [LOCAL] | WRITE} [, ...] explicit table-locking statement and its UNLOCK {TABLES | TABLE} release counterpart (one gate for the pair, the rename_statement precedent: MySQL’s lock/unlock grammar rules carry both — a dialect with one has both). This is the per-table lock-kind reading of the leading LOCK keyword — a do_statement/do_expression_list-style behaviour split: PostgreSQL’s LOCK [TABLE] <rel>, … [IN <mode> MODE] [NOWAIT] statement-level mode-list reading is a different behaviour on the same keyword and, when implemented, takes its own gate — a preset would arm at most one, so the shared leading LOCK/UNLOCK keywords dispatch unambiguously. MySQL-only among the shipped presets (plus the Lenient superset, where it is a pure addition today — no other LOCK-keyword statement exists; the union will owe a reading decision when the PostgreSQL form lands). Off elsewhere, where the leading keyword is not dispatched and surfaces as an unknown statement. See LockTablesStatement / UnlockTablesStatement.

lock_instance: bool

Accept the MySQL LOCK INSTANCE FOR BACKUP / UNLOCK INSTANCE instance-wide backup-lock pair (one gate for both, as with lock_tables — the same lock/unlock grammar rules carry them). A separate flag from lock_tables because the two surfaces are independent behaviours that only happen to share MySQL: the backup lock is a MySQL-8-specific administrative statement with no table list (MariaDB, for one, spells it BACKUP LOCK instead while sharing LOCK TABLES), and it is additionally collision-free with the future PostgreSQL mode-list reading (LOCK instance … continues with IN/NOWAIT/end there, never FOR). MySQL-only among the shipped presets (plus the Lenient superset). See InstanceLockStatement.

rename_statement: bool

Accept the MySQL standalone RENAME TABLE <a> TO <b>[, ...] and RENAME USER <u> TO <v>[, ...] object-rename statements (both → Statement::Rename). A leading-keyword gate like kill: off outside MySQL (and the Lenient superset), where the leading RENAME keyword is not dispatched and surfaces as an unknown statement. The two forms share one gate because MySQL’s single rename grammar rule carries both — a dialect with one has both. Distinct from the ALTER TABLE ... RENAME TO sub-clause, which is consumed by the ALTER TABLE grammar and never reaches this leading position.

signal_diagnostics: bool

Accept the MySQL diagnostics-area family — SIGNAL, RESIGNAL, and GET [CURRENT | STACKED] DIAGNOSTICS — as top-level statements (a leading-keyword gate like kill). One flag for all three: they are the single cohesive behaviour of manipulating the diagnostics area (raise / re-raise / read).

Its own axis, NOT the body-context compound_statements flag: these three attach to MySQL’s top-level simple_statement production and are engine-recognized at top level (measured 1295/ER_UNSUPPORTED_PS over the PREPARE oracle — grammar-valid, merely not preparable), exactly where a compound BEGIN … END block is NOT (a bare top-level BEGIN is transaction-start). Because the body dispatcher falls through to the top-level one for non-compound keywords, this single gate serves both surfaces. On for MySQL (and Lenient); off elsewhere, where the leading SIGNAL/RESIGNAL/GET keyword is left unconsumed and surfaces as an unknown statement.

export_import_database: bool

Accept the DuckDB EXPORT DATABASE ['<db>' TO] '<path>' [<copy-options>] catalogue dump and its IMPORT DATABASE '<path>' inverse. One flag gates both leading keywords because they are a single dialect unit — the two halves of one export/import round-trip, a dialect that dumps a database replays it (the same pairing reasoning attach uses for ATTACH/DETACH). DuckDB-only (and the permissive superset); off in ANSI, PostgreSQL, MySQL, and SQLite, which have no EXPORT/IMPORT DATABASE, so there the leading keywords are not dispatched and surface as unknown statements — the copy/attach leading-keyword-gate precedent.

update_extensions: bool

Accept the DuckDB UPDATE EXTENSIONS [( <name>, ... )] extension-refresh statement (Statement::UpdateExtensions). A refinement of the leading UPDATE, not a bare leading-keyword gate: a top-level UPDATE whose next word is the DuckDB-unreserved EXTENSIONS keyword is this statement only when that word is followed by the parenthesized name list or the statement end; an UPDATE extensions SET … (a table literally named extensions, or … AS e SET …) still routes to the DML UPDATE, exactly as DuckDB’s own grammar resolves the shared prefix (engine-probed on 1.5.4). Off for every non-DuckDB preset (bar the Lenient superset), where the EXTENSIONS lookahead is never taken and every UPDATE reaches the DML parser unchanged.

flush: bool

Accept the MySQL FLUSH [NO_WRITE_TO_BINLOG | LOCAL] <target> server-administration statement (Statement::Flush) — the {TABLE | TABLES} [<list>] [WITH READ LOCK | FOR EXPORT] form and the comma-separated keyword-target list (PRIVILEGES, LOGS, STATUS, RELAY LOGS FOR CHANNEL …, …). A leading-keyword gate like kill: on for MySQL (and the Lenient superset), off elsewhere, where the leading FLUSH keyword is not dispatched and surfaces as an unknown statement.

purge_binary_logs: bool

Accept the MySQL PURGE BINARY LOGS {TO '<log>' | BEFORE <datetime>} binary-log purge statement (Statement::Purge). A leading-keyword gate like kill: on for MySQL (and the Lenient superset), off elsewhere, where the leading PURGE keyword is not dispatched and surfaces as an unknown statement. Named for the only surviving 8.4 form — the deprecated MASTER synonym was removed, so this gate carries BINARY LOGS alone.

replication_statements: bool

Accept the MySQL replication-administration family (Statement::Replication) — CHANGE REPLICATION SOURCE TO <options>, CHANGE REPLICATION FILTER <rules>, START/STOP REPLICA, and START/STOP GROUP_REPLICATION. One gate for all five measured families because they are one cohesive dialect unit: MySQL’s replication-control surface, reached through the replication-specific leading-keyword sequences (CHANGE REPLICATION, START/STOP REPLICA, START/STOP GROUP_REPLICATION). A dialect either implements MySQL replication administration or it does not — Group Replication rides the same unit as classic asynchronous replication (both are the server’s replication control, not a severable syntax axis). A refinement of the shared START/STOP/CHANGE leading keywords (not a bare leading-keyword gate like kill): the dispatch claims START/STOP only when the next word is REPLICA/GROUP_REPLICATION and CHANGE only before REPLICATION, so START TRANSACTION and every other use of those keywords is untouched. On for MySQL (and the Lenient superset); off elsewhere, where the sequences are not dispatched and surface as unknown statements. MySQL 8.4 removed the legacy MASTER/SLAVE spellings, so only the REPLICATION/REPLICA grammar is accepted.

Implementations

impl UtilitySyntax

pub const ANSI: Self

The ANSI predefined value.

impl UtilitySyntax

pub const DATABRICKS: Self

Available on crate feature databricks only.

Databricks utility surface: the ANSI baseline plus the typed SHOW FUNCTIONS listing. This is the first typed-SHOW gate on under Databricks — the sibling SHOW TABLES/COLUMNS/CREATE TABLE gates are MySQL-shaped and stay off, but a bare SHOW FUNCTIONS listing is documented Spark/Databricks surface with a modelled, tested parser gate, so it clears the preset’s conservatism bar. Every other utility knob is conservatively ANSI.

impl UtilitySyntax

pub const DUCKDB: Self

Available on crate feature duckdb only.

The DUCKDB preset for utility syntax.

impl UtilitySyntax

pub const LENIENT: Self

Available on crate feature lenient only.

The LENIENT preset for utility syntax.

impl UtilitySyntax

pub const MYSQL: Self

Available on crate feature mysql only.

The MYSQL preset for utility syntax.

impl UtilitySyntax

pub const POSTGRES: Self

Available on crate feature postgres only.

The POSTGRES preset for utility syntax.

impl UtilitySyntax

pub const QUILTDB: Self

Available on crate feature quiltdb only.

Utility-statement syntax enabled by this preset.

impl UtilitySyntax

pub const SNOWFLAKE: Self

Available on crate feature snowflake only.

Snowflake utility surface: the ANSI baseline plus the COPY INTO bulk load/unload statement. Every other utility knob is conservatively ANSI — the PostgreSQL/DuckDB COPY, COMMENT ON, the SQLite/MySQL statements, and the prepared-statement lifecycle all stay off.

impl UtilitySyntax

pub const SQLITE: Self

Available on crate feature sqlite only.

The SQLITE preset for utility syntax.

Trait Implementations

impl Clone for UtilitySyntax

fn clone(&self) -> UtilitySyntax

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for UtilitySyntax

impl Debug for UtilitySyntax

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for UtilitySyntax

impl PartialEq for UtilitySyntax

fn eq(&self, other: &UtilitySyntax) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for UtilitySyntax