pub struct ViewSequenceClauseSyntax {
pub create_sequence_cache: bool,
pub materialized_view_to: bool,
pub temporary_views: bool,
pub recursive_views: bool,
pub view_definition_options: bool,
}Expand description
Dialect-owned whole-statement DDL dispatch gates accepted by the parser. Dialect-owned view/sequence clause syntax accepted after a DDL statement head.
Post-dispatch refinements on CREATE VIEW / CREATE MATERIALIZED VIEW / CREATE SEQUENCE
— temporary views, recursive views, view WITH options, matview TO target, sequence
CACHE — split out of StatementDdlGates so whole-statement object-kind gates stay
separate from clause-level grammar. Statement-head flags (create_sequence,
materialized_views, or_replace, …) remain on StatementDdlGates.
Fields§
§create_sequence_cache: boolAccept CACHE <n> in the option list of CREATE SEQUENCE.
materialized_view_to: boolAccept a materialized-view storage target: CREATE MATERIALIZED VIEW name TO target AS ....
temporary_views: boolAccept the TEMP/TEMPORARY modifier on a plain CREATE [OR REPLACE] VIEW
(PostgreSQL/SQLite/DuckDB spell session-local views). On for ANSI/PostgreSQL/SQLite/
DuckDB/Lenient. MySQL has no temporary views (only temporary tables), so it is off;
a consumed TEMP/TEMPORARY prefix leading into VIEW is then the syntax error
MySQL reports (engine-measured-rejected on mysql:8). Gates only the view surface — the
CREATE TEMPORARY TABLE form is a separate, unaffected family.
recursive_views: boolAccept the RECURSIVE keyword before VIEW in CREATE [OR REPLACE] [TEMP|TEMPORARY] RECURSIVE VIEW <name> (<columns>) AS <query> (DuckDB,
engine-measured on duckdb 1.5.4). On for DuckDB/Lenient only — although
PostgreSQL spells the same form, it is gated to the measured dialect per the
no-shadowing doctrine rather than widened to the PostgreSQL reference without a
differential. Off elsewhere, where the RECURSIVE keyword is left unconsumed
before the expected VIEW and surfaces as a clean parse error. The keyword sits
between the TEMP/TEMPORARY prefix and VIEW, never composes with
MATERIALIZED, and requires the explicit column list (the engine desugars a
recursive view to WITH RECURSIVE, which names its output columns).
view_definition_options: boolAccept MySQL’s view definition-option surface: the [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = <user>] [SQL SECURITY {DEFINER | INVOKER}] prefix (before the
VIEW keyword) on CREATE VIEW, and the whole ALTER VIEW redefinition statement,
dispatched to the AlterView node. One flag gates both because
they are the one MySQL view-definition behaviour — the identical ViewOptions
prefix decorates CREATE VIEW and heads ALTER VIEW, and no dialect has one without the
other. On for MySQL/Lenient. Off elsewhere: the option keywords before VIEW are left
unconsumed (a clean parse error), and ALTER VIEW routes only to the DuckDB
alter_object_set_schema SET SCHEMA head
where that flag is on. A separate behaviour from that schema-relocation gate: this is
the redefinition/option surface, that is the cross-schema move.
Implementations§
Trait Implementations§
Source§impl Clone for ViewSequenceClauseSyntax
impl Clone for ViewSequenceClauseSyntax
Source§fn clone(&self) -> ViewSequenceClauseSyntax
fn clone(&self) -> ViewSequenceClauseSyntax
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more