pub struct TableFactorSyntax {Show 17 fields
pub lateral: bool,
pub table_functions: bool,
pub rows_from: bool,
pub unnest: bool,
pub unnest_with_offset: bool,
pub table_function_ordinality: bool,
pub special_function_table_source: bool,
pub pivot: bool,
pub unpivot: bool,
pub show_ref: bool,
pub from_values: bool,
pub json_table: bool,
pub xml_table: bool,
pub table_expr_factor: bool,
pub pivot_value_sources: bool,
pub match_recognize: bool,
pub open_json: bool,
}Expand description
Dialect-owned table-factor syntax accepted by the parser.
The FROM-item factor forms beyond a plain named table. Split out of
TableExpressionSyntax at its 16-field line as the table-factor axis, distinct from
the join and factor-tail/alias cores. Each flag is a grammar gate: when off the factor
keyword falls through to the named-table path or surfaces as a clean parse error.
Fields§
§lateral: boolAccept LATERAL before derived tables and table functions.
table_functions: boolAccept function calls as FROM items.
rows_from: boolAccept PostgreSQL ROWS FROM (...) table functions.
unnest: boolAccept the first-class UNNEST(<expr>[, <expr>…]) table factor
(TableFactor::Unnest) — an array/collection
expression expanded into a relation, with optional WITH ORDINALITY, a
correlation alias, and (under unnest_with_offset)
a BigQuery WITH OFFSET tail. On for PostgreSQL/DuckDB/Lenient (each admits
FROM unnest(…)); off for ANSI/MySQL/SQLite, where UNNEST( is left to the
named-table path and — with those presets’ table_functions
also off — surfaces as the same clean parse error as any other function-in-FROM.
Distinct from table_functions: a dialect can admit
generic table functions yet route UNNEST to this dedicated node.
unnest_with_offset: boolAccept the BigQuery/ZetaSQL WITH OFFSET [AS <alias>] tail on an
unnest table factor — a 0-based ordinal column, the BigQuery
counterpart of PostgreSQL’s WITH ORDINALITY; the dependency is
FeatureDependencyViolation::UnnestWithOffsetWithoutUnnest. On for the BigQuery
preset alone — the first shipped dialect to enable it; off for every oracle-compared
preset (PostgreSQL and DuckDB both parse-reject WITH OFFSET, engine-probed) and
off for Lenient, and BigQuery carries no differential oracle. When off, a
trailing WITH OFFSET is left unconsumed and the statement rejects.
table_function_ordinality: boolAccept a WITH ORDINALITY tail on a table-valued FROM source — the generic
function factor, an unnest factor, and a
rows_from factor — adding a trailing ordinal column. On for
PostgreSQL/DuckDB/Lenient; off for SQLite, whose grammar admits generic
table_functions but syntax-rejects WITH ORDINALITY
(engine-probed: FROM pragma_table_info('t') WITH ORDINALITY errors at
ORDINALITY). When off, the trailing WITH ORDINALITY is left unconsumed and the
statement rejects. Distinct from unnest_with_offset,
the BigQuery WITH OFFSET counterpart.
special_function_table_source: boolAccept a bare SQL special value function (current_date, current_timestamp,
current_user, …) as a FROM table source — PostgreSQL’s func_table
promotion of a SQLValueFunction (TableFactor::SpecialFunction),
e.g. SELECT * FROM current_date. On for ANSI/PostgreSQL/SQLite/DuckDB/Lenient.
MySQL has no such promotion — current_date/current_timestamp are reserved and a
bare one in table position is an ER_PARSE_ERROR on mysql:8 — so it is off there,
and the special-function keyword then falls through to the named-table path where the
reserved-word gate rejects it (exactly as the alias position already does).
pivot: boolAccept DuckDB’s PIVOT operator (Pivot) in both of its
surfaces: the <source> PIVOT (<aggs> FOR <col> IN (<vals>)) table factor and
the leading-keyword PIVOT <source> ON … USING … statement. One flag gates both
grammar points because they are a single dialect unit — DuckDB always admits the
statement wherever it admits the table factor (the straight_join
precedent). The flag alone is not enough on a bare table factor: PIVOT must
also be in FeatureSet::reserved_bare_alias or the source’s alias swallows it
first (the DuckDb preset reserves it, class reserved like QUALIFY). On for
DuckDb / Lenient, off elsewhere.
unpivot: boolAccept DuckDB’s UNPIVOT operator (Unpivot) in both its
table-factor and leading-keyword-statement surfaces — the pivot
counterpart, kept a separate flag because PIVOT and UNPIVOT are distinct
operators (the asof_join/positional_join
precedent). The same reserved-word interaction applies. On for DuckDb / Lenient,
off elsewhere.
show_ref: boolAccept DuckDB’s DESCRIBE/SHOW/SUMMARIZE utility as a parenthesized FROM
table source — DuckDB’s SHOW_REF table reference
(TableFactor::ShowRef), e.g.
FROM (DESCRIBE SELECT …), FROM (SHOW databases). One flag gates all three
keywords because DuckDB models them as a single SHOW_REF production (the
paired-flag doctrine). When off, the leading keyword is left to the query/join
grammar inside the parentheses and the construct is a clean parse divergence
(FROM (DESCRIBE …) reads DESCRIBE as neither a query start nor a joined
table). Only the table-source position is admitted — DuckDB parse-rejects these
at CTE-body position — so, unlike pivot, there is no query-body
or leading-keyword-statement surface. On for DuckDb / Lenient, off elsewhere.
from_values: boolAccept DuckDB’s bare FROM VALUES (<row>, …) AS <alias> row-list table factor —
a VALUES constructor standing directly as a table factor without the wrapping
parentheses the standard derived table requires
(TableFactor::Derived tagged
DerivedSpelling::BareValues). DuckDB
parse-requires a table alias here (a bare FROM VALUES (1) is a syntax error;
FROM VALUES (1) t accepts — probed on 1.5.4), so the parser rejects a missing
one. When off, VALUES in table-factor position is not a table name and the
construct is a clean parse divergence (the reject the other dialects give). The
parenthesized FROM (VALUES …) derived table is separate and always accepted. On
for DuckDb / Lenient, off elsewhere.
json_table: boolAccept the SQL/JSON JSON_TABLE(context, path [AS name] [PASSING …] COLUMNS (…) [… ON ERROR]) table factor (TableFactor::JsonTable). On
for PostgreSQL/Lenient. Off elsewhere: DuckDB parse-rejects it, and MySQL’s JSON_TABLE
has a different grammar (kept off so this PG-shaped node never fires for it). When
off, JSON_TABLE( falls to the ordinary function/name path; reached only when the
keyword is immediately followed by (.
xml_table: boolAccept the SQL/XML XMLTABLE([XMLNAMESPACES(…),] row PASSING doc COLUMNS …) table
factor (TableFactor::XmlTable). On for PostgreSQL/Lenient,
off elsewhere (DuckDB parse-rejects it; MySQL/SQLite/ANSI have no such form). When off,
XMLTABLE( falls to the ordinary function/name path; reached only when the keyword is
immediately followed by (.
table_expr_factor: boolAccept TABLE(<expr>) as a first-class FROM table factor
(TableFactor::TableExpr) — sqlparser-rs’s
TableFunction. Distinct from table_functions (a
named table function, FROM f(1)) and from the standalone TABLE t query
form, which is not a FROM-position factor at all. Snowflake and Oracle are the
engines that document this shape, but neither ships a differential oracle here,
so over-acceptance is unmeasurable — the conservative-preset family rule keeps
this off everywhere but Lenient (the permissive superset), with no oracle-backed
preset enabling it. When off, TABLE( in table-factor position falls through to
the named-table path, where the reserved TABLE keyword is not an admissible
relation name and the construct is a clean parse error.
pivot_value_sources: boolAccept the SQL-standard PIVOT table factor’s extended value sources and default —
the Snowflake/BigQuery/Oracle grammar layered on the shared
<source> PIVOT (<aggs> FOR <col> IN (…)) shape: the IN (ANY [ORDER BY …])
wildcard and IN (<subquery>) value sources
(PivotValueSource) and the Snowflake
DEFAULT ON NULL (<expr>) tail (Pivot::default_on_null).
Also the reachability gate for the standard single-FOR-column table-factor
PIVOT itself where the DuckDB pivot flag is off — so with pivot
off and this on the parser reads the table-factor PIVOT but not the DuckDB
leading-keyword statement / query-body / IN <enum> forms, and stops the
bare-chained multi-FOR-column list at one head (the standard admits exactly one).
On for BigQuery / Snowflake / Lenient — none oracle-compared here, so
over-acceptance is unmeasurable and the conservative-preset family rule keeps it
off elsewhere. Like pivot, a bare-factor standard PIVOT is
reachable only where PIVOT is in FeatureSet::reserved_bare_alias; where it is
not (BigQuery/Snowflake today), the suffix fires after an explicit alias — the
pivot/ASOF reservation-dependency precedent.
It doubles as the reachability gate for the standard UNPIVOT table factor where
the DuckDB unpivot flag is off: PIVOT and UNPIVOT co-travel in
these engines’ grammars (every dialect with the standard PIVOT table factor also
has UNPIVOT), so one flag reaches both rather than a redundant sibling that no
dialect would ever toggle apart. The UNPIVOT table factor grammar is fully
shared — the INCLUDE/EXCLUDE NULLS marker, per-column aliases, and multi-column
value/name lists are all DuckDB fields BigQuery/Snowflake reuse — so this gate adds
no new UNPIVOT syntax, only reachability; the same explicit-alias reachability note
applies to a bare-factor standard UNPIVOT.
match_recognize: boolAccept the SQL:2016 <source> MATCH_RECOGNIZE (…) row-pattern-recognition table
factor (MatchRecognize) — the Snowflake / Oracle
row-pattern-matching clause, with its PARTITION BY / ORDER BY / MEASURES /
ONE|ALL ROWS PER MATCH / AFTER MATCH SKIP / PATTERN (…) / SUBSET / DEFINE
subclauses. On for Snowflake (documented; no differential oracle, so
over-acceptance is unmeasurable and the conservative-preset family rule keeps it
off elsewhere) and Lenient (the permissive superset). Oracle is not a shipped
preset, so it does not enable this. Like pivot, a bare-factor
MATCH_RECOGNIZE is reachable only where the keyword is in
FeatureSet::reserved_bare_alias; where it is not, the suffix fires after an
explicit alias — the pivot/ASOF reservation-dependency precedent. When off,
MATCH_RECOGNIZE falls through to the named-table/alias path and the construct is
a clean parse divergence.
open_json: boolAccept SQL Server’s OPENJSON(<json> [, <path>]) [WITH (<col> <type> [<path>] [AS JSON], …)] rowset-function table factor (OpenJson) — a JSON document
parsed into a relation, either with the default key/value/type schema (no WITH)
or an explicit column schema. On for MSSQL (documented — SQL Server is the sole engine
with this exact form; no differential oracle ships, so over-acceptance is unmeasurable
and the conservative-preset family rule keeps it off elsewhere) and Lenient (the
permissive superset). OPENJSON is unreserved (a rowset function name), so this fires
only when the keyword is immediately followed by (; a bare OPENJSON stays an ordinary
relation name. When off, OPENJSON( falls to the ordinary function/name path, which
rejects at the WITH (…) clause tail — the json_table precedent.
Docs: https://learn.microsoft.com/en-us/sql/t-sql/functions/openjson-transact-sql.
Implementations§
Source§impl TableFactorSyntax
impl TableFactorSyntax
Sourcepub const DATABRICKS: Self
Available on crate feature databricks only.
pub const DATABRICKS: Self
databricks only.The DATABRICKS preset for table factor syntax.
Source§impl TableFactorSyntax
impl TableFactorSyntax
Sourcepub const SNOWFLAKE: Self
Available on crate feature snowflake only.
pub const SNOWFLAKE: Self
snowflake only.Snowflake table-factor surface: the ANSI baseline plus the standard PIVOT table
factor (FROM t PIVOT(<agg> FOR <col> IN (<vals> | ANY [ORDER BY …] | <subquery>) [DEFAULT ON NULL (<expr>)]))). Snowflake has no differential oracle here, so the
gate follows the documented grammar on this conservative preset (the qualify
precedent). The DuckDB pivot flag stays off — Snowflake has no
leading-keyword PIVOT statement, IN <enum>, or multi-FOR-column form.
Trait Implementations§
Source§impl Clone for TableFactorSyntax
impl Clone for TableFactorSyntax
Source§fn clone(&self) -> TableFactorSyntax
fn clone(&self) -> TableFactorSyntax
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more