Module view_ddl 

CREATE [OR REPLACE] MATERIALIZED VIEW / DROP MATERIALIZED VIEW DDL: parsing and the admin gate. CREATE [OR REPLACE] MATERIALIZED VIEW ... WITH (...) / DROP MATERIALIZED VIEW ... – the DDL front end for DDL-defined eagerly materialized views.

All three queries (extract_query, count_src_query, merge_partitions_query) are WITH options, so none of them is privileged the way a statement body would be – that requires parsing the statement directly instead of going through sqlparser’s own parse_create_view, which unconditionally expects an AS body immediately after the view name and so cannot parse a CREATE MATERIALIZED VIEW ... WITH (...) with no AS body at all. [parse_view_ddl] therefore hand-rolls the parse off a single Parser::try_with_sql.

Enums

ViewDdl

One parsed CREATE [OR REPLACE] MATERIALIZED VIEW / DROP MATERIALIZED VIEW statement.

Functions

authorize_view_ddl

The same admin gate as the nine admin-gated lakehouse UDTFs/UDFs (query.rs::register_lakehouse_functions’s if lakehouse_admin block), pulled out as a standalone function since this path never builds a caller session context to register a UDTF against in the first place. Also load-bearing beyond the usual reason: a DDL view’s queries are planned and materialized under CallerContext::maintenance() (ReadScope::All), so an author sees every audience regardless of their own read scope.

parse_view_ddl

Ok(None) when sql is not view DDL – the overwhelmingly common case, decided by a cheap keyword peek before any full parse. Err when the hand-rolled parse does not reach EOF right after <name> WITH (...) (or, on DROP, right after the single name): an unmodelled clause, an AS body, a second DROP name, or a second statement each would otherwise silently do less than the statement says.