Enum KeywordOperators 

pub enum KeywordOperators {
    Unsupported,
    MySql,
    Sqlite,
    DuckDb,
}

Whether a dialect treats MySQL’s reserved-keyword infix operators — DIV, MOD, XOR, RLIKE, REGEXP — as operators.

MySQL spells these infix operators as keywords rather than symbols; ANSI and PostgreSQL have none of them (the words are ordinary identifiers there). Which keywords act as operators is therefore an explicit dialect-data decision, the keyword analogue of PipeOperator/DoubleAmpersand: this maps a reserved keyword token to the canonical BinaryOperator it folds onto. Precedence is not stored here — each operator’s binding power is owned by the BindingPowerTable (DIV/MOD multiplicative, XOR between AND and OR, RLIKE/REGEXP comparison), so meaning and precedence cannot drift.

The MySql variant is named for a dialect, not the capability it grants — the lone place a FeatureSet value is dialect-named — and that is deliberate. A variant here denotes one dialect’s exact keyword-operator set (MySQL’s DIV/MOD/XOR/RLIKE/REGEXP mapping), which is a specification, not a composable capability: a future dialect with a different set gets its own variant rather than reusing this one, so the dialect name is the spec. A capability name like DivModXorRegexp would only restate that mapping, less precisely and with no room for the next dialect’s variant.

Variants

Unsupported

No keyword infix operators (ANSI/PostgreSQL): DIV/MOD/XOR/RLIKE/REGEXP are ordinary identifiers, so in infix position they end the expression.

MySql

The MySQL keyword infix operators: DIV, MOD, XOR, RLIKE, REGEXP.

Sqlite

The SQLite keyword infix operators: GLOB, MATCH, REGEXP. Like MySql, the variant is named for the dialect whose exact keyword-operator set it denotes (a specification, not a composable capability), per the dialect-named-variant rationale documented on this enum. GLOB is a built-in the differential oracle can verify; MATCH/REGEXP are grammar hooks backed by application-defined functions the bundled engine does not register, so they parse but a bare prepare rejects them — grammar-only siblings.

DuckDb

DuckDB’s keyword infix set is just GLOB (engine-probed on 1.5.4: MATCH / REGEXP are not keyword infix operators there). Named for the dialect’s exact set, same rationale as Sqlite.

Implementations

impl KeywordOperators

pub const fn binary_operator(self, keyword: Keyword) -> Option<BinaryOperator>

The canonical binary operator keyword maps to as an infix operator under this dialect, or None when keyword is not a keyword operator here.

The MOD and RLIKE/REGEXP keywords fold onto the shared modulo/regex operators with a surface tag so the exact spelling round-trips; DIV and XOR are their own operator keys.

Trait Implementations

impl Clone for KeywordOperators

fn clone(&self) -> KeywordOperators

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for KeywordOperators

impl Debug for KeywordOperators

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

Formats the value using the given formatter.

impl Eq for KeywordOperators

impl PartialEq for KeywordOperators

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

Equality operator ==.

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

Inequality operator !=.

impl StructuralPartialEq for KeywordOperators