pub struct IdentifierSyntax {
pub dollar_in_identifiers: bool,
pub string_literal_identifiers: bool,
pub empty_quoted_identifiers: bool,
}Expand description
Dialect-owned policy for which characters form an unquoted identifier.
The identifier-start and identifier-continue classes are an explicit,
Unicode-aware policy, not an ad-hoc byte rule. The default mirrors
PostgreSQL — the M1 reference dialect: an identifier starts with a Unicode
letter (char::is_alphabetic) or _, and continues with a letter, a Unicode
digit (char::is_alphanumeric), _, or — where dollar_in_identifiers is
set — $. Quoted identifiers bypass the policy entirely (any character may be
quoted), and no identifier normalization (NFC/NFKC) is performed — characters
are compared as written; case folding for identity is the separate
identifier_casing concern.
Only the dialect-variable part lives here. The ASCII letter/digit/_ classes
are the shared byte-class table (so a dialect can still add ASCII identifier bytes
like T-SQL #/@ through byte_classes), and the non-ASCII rule is the fixed
Unicode letter/alphanumeric property. The one knob that genuinely differs across
shipped dialects is $.
Fields§
§dollar_in_identifiers: boolAccept $ as an identifier-continue character (foo$bar), a PostgreSQL /
Oracle extension that strict ANSI forbids. $ never starts an identifier (a
leading $ is a parameter or dollar-quote), and it is never a dollar-quote
tag character (there $ is the delimiter).
string_literal_identifiers: boolAccept a single-quoted string literal in identifier positions beyond aliases —
SQLite’s misfeature where a 'name' string is read as a name wherever the grammar
wants a nm (identifier). Corpus-admitted for the two positions the SQLite
test-suite surfaces: a DML/DDL relation-target name (DELETE FROM 'table1', and
so CREATE TABLE 'name' / DROP TABLE 'n' / INSERT INTO 'n' through the shared
target path) and a PRIMARY KEY/UNIQUE table-constraint column-name list
(PRIMARY KEY('a'), UNIQUE('b')). Each admitted position is position-driven:
a bare string there is never a valid literal in standard SQL, so reading it as the
name is unambiguous — no lexical or grammar conflict (the tokenizer still lexes
'x' to a String; a single parser position reads it, shadowing no rival feature).
SQLite’s full leniency is broader (a string is also admitted as a column-def name,
a CAST type name, a qualified column-ref qualifier, a CREATE VIEW/TRIGGER
target, …); those positions carry no corpus gap and stay out of scope. A string
function name is a SQLite syntax error (SELECT 'f'(1)), so the widening is
deliberately confined to the two name positions rather than folded into the shared
object-name grammar. The folded name records QuoteStyle::Single (or Double
under a no-ANSI_QUOTES mode) so the quotes round-trip, reusing the projection
alias’s string round-trip. On for SQLite / Lenient, off elsewhere — every other
dialect syntax-rejects the form, so the over-acceptance risk is zero (flag off).
empty_quoted_identifiers: boolAccept a zero-length delimited (quoted) identifier — the empty backtick
, the empty bracket `[]`, and the empty double-quote `""` — which SQL's `<delimited identifier body>` and PostgreSQL/MySQL both forbid at scan time. SQLite alone among the shipped engines admits an empty quoted identifier in every quote style (engine-measured on rusqlite: SELECT , SELECT [], and SELECT ""
all prepare — the "" via SQLite’s double-quote-to-string fallback, the others as
zero-length names). When off, the tokenizer rejects a zero-length quoted identifier
the moment the close abuts the open (the pre-existing, universal
ZeroLengthDelimitedIdentifier scan reject). On for SQLite / Lenient, off elsewhere.
Implementations§
Trait Implementations§
Source§impl Clone for IdentifierSyntax
impl Clone for IdentifierSyntax
Source§fn clone(&self) -> IdentifierSyntax
fn clone(&self) -> IdentifierSyntax
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more