Struct AccessControlSyntax 

pub struct AccessControlSyntax {
    pub access_control: bool,
    pub access_control_extended_objects: bool,
    pub user_role_management: bool,
    pub access_control_account_grants: bool,
}

Dialect-owned access-control-statement syntax accepted by the parser.

The GRANT/REVOKE permission statements and their extended object/prefix grammar. Split out of UtilitySyntax at its 16-field line as the access-control axis. Each flag is a grammar gate: when off the keyword is not dispatched, or the extended object grammar rejects, as the dialect requires.

Fields

access_control: bool

Accept the access-control statements GRANT … / REVOKE … (SQL:2016 E081; PostgreSQL/MySQL). On for ANSI/PostgreSQL/MySQL/DuckDB/Lenient. SQLite has no permission system, so it is off; the leading keyword is then not dispatched and surfaces as an unknown statement.

access_control_extended_objects: bool

Accept the PostgreSQL/standard extended GRANT/REVOKE object and prefix grammar on top of the base access_control statements (the dependency is FeatureDependencyViolation::AccessControlExtendedObjectsWithoutAccessControl): a schema-scoped object (ON SCHEMA s, ON DATABASE d), the ON ALL <kind> IN SCHEMA s bulk form, and the {GRANT | ADMIN} OPTION FOR REVOKE prefix. On for ANSI/PostgreSQL/DuckDB/Lenient. MySQL admits GRANT/REVOKE but not these forms — its object grammar is ON [TABLE | FUNCTION | PROCEDURE] priv_level, and SCHEMA / DATABASE are reserved words that cannot introduce a priv_level, so those objects and the OPTION FOR prefix are the syntax error MySQL reports (engine-measured on mysql:8 — GRANT … ON SCHEMA s, REVOKE GRANT OPTION FOR … , REVOKE … ON SCHEMA s all ER_PARSE_ERROR), so it is off there. The bare/TABLE/FUNCTION/PROCEDURE objects, WITH GRANT OPTION, and the role-membership GRANT r TO u / REVOKE r FROM u forms are unaffected (MySQL accepts them), so the gate never over-rejects MySQL’s supported surface. (SQLite has no permission system, so access_control is already off there and this is moot.) Never both on with the MySQL account route access_control_account_grants — the pair is the registered GrammarConflict::AccountGrantsVersusExtendedObjects, where the route dispatches its grammar before this extended-object reading is consulted.

user_role_management: bool

Accept the MySQL account-management DDL family — CREATE/ALTER/DROP USER, CREATE/DROP ROLE — with its shared account-name (user@host / CURRENT_USER), authentication (IDENTIFIED BY/WITH), TLS (REQUIRE), resource (WITH …), and password/lock option surface. On for MySQL/Lenient. Off elsewhere (no other dialect models MySQL accounts): the leading USER/ROLE after CREATE/ALTER/DROP is then not dispatched and surfaces as the ordinary TABLE-expectation parse error. Independent of access_control (GRANT/REVOKE): a dialect can admit privilege statements without the account-management DDL, and vice versa.

access_control_account_grants: bool

Dispatch GRANT/REVOKE through the MySQL account-based grammar rather than the standard/PostgreSQL one (the dependency is FeatureDependencyViolation::AccountGrantsWithoutAccessControl): the object is a priv_level (*, *.*, db.*, db.tbl) rather than a typed object with a name list, every grantee/role is a user@host account rather than a role spec, and the grammar adds PROXY grants, the AS <user> [WITH ROLE …] grantor context, the [IF EXISTS] … [IGNORE UNKNOWN USER] REVOKE guards, and the REVOKE ALL PRIVILEGES, GRANT OPTION form — while dropping GRANTED BY, CASCADE/RESTRICT, and the {GRANT | ADMIN} OPTION FOR prefix (all engine-measured ER_PARSE_ERROR on mysql:8.4.10).

On for MySQL only. It is a route, not an additive layer: the MySQL priv_level/account object and grantee grammar structurally conflicts with the PostgreSQL typed-object/role-spec grammar (one input, one AST — they cannot both be represented), so a dialect cannot enable both grant grammars at once — enabling this route alongside access_control_extended_objects is the registered GrammarConflict::AccountGrantsVersusExtendedObjects, the route deadening the extended-object reading. That is why the Lenient permissive superset keeps this off — it retains the richer PostgreSQL-extended grant grammar (schema objects, GRANTED BY, CASCADE, routine signatures) that access_control_extended_objects governs, which a route to the MySQL grammar would forfeit. Requires access_control: the MySQL forms are still GRANT/REVOKE statements, unreachable without the base dispatch.

Implementations

impl AccessControlSyntax

pub const ANSI: Self

The ANSI predefined value.

impl AccessControlSyntax

pub const DATABRICKS: Self

Available on crate feature databricks only.

The DATABRICKS preset for access control syntax.

impl AccessControlSyntax

pub const DUCKDB: Self

Available on crate feature duckdb only.

The DUCKDB preset for access control syntax.

impl AccessControlSyntax

pub const LENIENT: Self

Available on crate feature lenient only.

The LENIENT preset for access control syntax.

impl AccessControlSyntax

pub const MYSQL: Self

Available on crate feature mysql only.

The MYSQL preset for access control syntax.

impl AccessControlSyntax

pub const POSTGRES: Self

Available on crate feature postgres only.

The POSTGRES preset for access control syntax.

impl AccessControlSyntax

pub const SQLITE: Self

Available on crate feature sqlite only.

The SQLITE preset for access control syntax.

Trait Implementations

impl Clone for AccessControlSyntax

fn clone(&self) -> AccessControlSyntax

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for AccessControlSyntax

impl Debug for AccessControlSyntax

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

Formats the value using the given formatter.

impl Eq for AccessControlSyntax

impl PartialEq for AccessControlSyntax

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

Equality operator ==.

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

Inequality operator !=.

impl StructuralPartialEq for AccessControlSyntax