pub struct AccessControlSyntax {
pub alter_role_rename: bool,
pub access_control: bool,
pub access_control_extended_objects: bool,
pub user_role_management: bool,
pub access_control_account_grants: bool,
}Expand description
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§
§alter_role_rename: boolAccept PostgreSQL ALTER ROLE <name> RENAME TO <new_name>.
access_control: boolAccept 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: boolAccept 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: boolAccept 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: boolDispatch 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§
Source§impl AccessControlSyntax
impl AccessControlSyntax
Sourcepub const DATABRICKS: Self
Available on crate feature databricks only.
pub const DATABRICKS: Self
databricks only.The DATABRICKS preset for access control syntax.
Trait Implementations§
Source§impl Clone for AccessControlSyntax
impl Clone for AccessControlSyntax
Source§fn clone(&self) -> AccessControlSyntax
fn clone(&self) -> AccessControlSyntax
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more