Struct NumericLiteralSyntax 

pub struct NumericLiteralSyntax {
    pub hex_integers: bool,
    pub octal_integers: bool,
    pub binary_integers: bool,
    pub underscore_separators: bool,
    pub radix_leading_underscore: bool,
    pub reject_trailing_junk: bool,
    pub money_literals: bool,
}

Dialect-owned numeric literal syntax extensions.

Standard decimal/scientific numbers are always part of the baseline. These flags cover non-ANSI numeric forms whose recognition is an explicit dialect data decision. Each is lexical: it widens which numbers the scanner accepts as one token; value materialization stays deferred. The radix and separator forms below are PostgreSQL 14+ additions (also in T-SQL / MySQL for hex), so a release-pinned PostgreSQL preset gates them by version.

Fields

hex_integers: bool

Accept 0x.. hexadecimal integer literals (T-SQL, MySQL, PostgreSQL 14+).

octal_integers: bool

Accept 0o.. octal integer literals (PostgreSQL 14+).

binary_integers: bool

Accept 0b.. binary integer literals (MySQL, PostgreSQL 14+).

underscore_separators: bool

Accept _ digit-group separators between digits (PostgreSQL 14+), e.g. 1_500_000. Recognised lexically only when a digit follows the _. When reject_trailing_junk is off the placement is loose (a _ is a separator wherever a digit follows it); when it is on the placement is strict (a decimal _ must sit between two digits, matching PG’s {decdigit}(_?{decdigit})*), so a leading-in-fraction/trailing/doubled _ stops the number and surfaces as trailing junk. Whether a _ may additionally lead a radix body (0x_1F) is a separate axis (radix_leading_underscore), because PG and SQLite disagree on it.

radix_leading_underscore: bool

Accept a leading _ immediately after a radix marker, before the first radix digit (0x_1F, 0b_101) — PostgreSQL’s 0[xX](_?{hexdigit})+ grammar, which admits the underscore ahead of the first digit. Requires underscore_separators; an interior radix _ (0x1_F) rides that flag alone and is unaffected by this one.

Its own axis rather than a rider on reject_trailing_junk because the engines that reject trailing junk still split on it: PostgreSQL accepts 0x_1F (probed) but SQLite rejects it — SQLite’s radix grammar is 0[xX]{hexdigit}(_?{hexdigit})*, requiring a digit before the first _. With this off a leading-underscore radix body does not open, so 0x_1F falls back to the bare 0 plus a x_1F word/alias (loose dialects) or a trailing-junk reject (strict ones), exactly as before this axis existed.

reject_trailing_junk: bool

Reject an identifier-start character abutting a numeric literal — PostgreSQL’s “trailing junk after numeric literal” scanner error (123abc, 1x, 0.0e, 100_), plus the bad-radix (0x, 0b0x) and misplaced-separator (100__000, 1_000._5) forms that decompose to it. A number is a maximal-munch lexeme, so with this on anything identifier-ish immediately following one is a lexer error, not a new token; it also switches underscore_separators to strict placement.

Dialect-gated because the reject is not universal: PostgreSQL and SQLite reject these (both probed against their engines), but DuckDB accepts them all (it re-reads 123abc as 123 aliased) and MySQL only rejects the integer/radix forms — so a dialect that lexes its numerics loosely (DuckDB/MySQL) leaves this off and the trailing text falls through to the ordinary word/alias scan, exactly as before.

money_literals: bool

Accept $1234.56 / $.5 T-SQL money literals (the $ currency sigil prefixes a decimal). Off in ANSI/PostgreSQL: PostgreSQL spells $ as a positional parameter ($1) or a dollar-quote ($tag$), never money, so the three $-prefix lexer forms are dialect-disjoint. Lexes as a Number token spanning the $; the money type rides the literal kind and the sigil is stripped at the accessor, like the B/X bit-string prefix.

Implementations

impl NumericLiteralSyntax

pub const ANSI: Self

The ANSI predefined value.

impl NumericLiteralSyntax

pub const DUCKDB: Self

Available on crate feature duckdb only.

The DUCKDB preset for numeric literal syntax.

impl NumericLiteralSyntax

pub const LENIENT: Self

Available on crate feature lenient only.

LENIENT: every radix and separator form, but not money_literals.

money_literals is OFF because $+digit is a positional parameter here (conflict-resolution rule 3): the two cannot coexist, and $1 parameters are the dominant real-world meaning.

impl NumericLiteralSyntax

pub const MSSQL: Self

Available on crate feature mssql only.

MSSQL numeric surface: the ANSI baseline plus $1234.56 / $.5 money literals. Every other numeric knob is conservatively ANSI.

impl NumericLiteralSyntax

pub const MYSQL: Self

Available on crate feature mysql only.

The MYSQL preset for numeric literal syntax.

impl NumericLiteralSyntax

pub const POSTGRES: Self

Available on crate feature postgres only.

The POSTGRES preset for numeric literal syntax.

impl NumericLiteralSyntax

pub const SQLITE: Self

Available on crate feature sqlite only.

The SQLITE preset for numeric literal syntax.

Trait Implementations

impl Clone for NumericLiteralSyntax

fn clone(&self) -> NumericLiteralSyntax

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for NumericLiteralSyntax

impl Debug for NumericLiteralSyntax

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

Formats the value using the given formatter.

impl Eq for NumericLiteralSyntax

impl PartialEq for NumericLiteralSyntax

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

Equality operator ==.

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

Inequality operator !=.

impl StructuralPartialEq for NumericLiteralSyntax