Module statements

Expand description

Executable statement schemas and mutation parameter analysis.

Structs§

AnalyzedStatement: Analyzed syntax with immutable input conversions and no optimized access paths. A caller must validate the original statement, catalog, namespace, authority and parser settings in the selected statement snapshot before offering this entry for reuse. Parameter values remain supplied by each execution; their inferred types and explicit declarations must still match.
ProceduralPlanAnalysis
StatementAnalysisContext

AnalyzedResult: The result a statement’s analysis derives: the column types of a query or of a data-modifying statement’s RETURNING list, None where analysis derives no type, or no result for any other statement.

StatementAnalysisScopes: Retain a fresh catalog, namespace and transition scope for each statement analysis.
StatementBindingScope: Borrow binding inputs only when the statement’s semantic branch requires them.

analyze_command_parameters
analyze_executable_plan
analyze_executable_plan_for_cache: Analyze once and report whether the converted inputs can be reused by a later ordinary message. Prepared definitions use their separate creation lifetime.
analyze_for_statement_reuse: Analyze under the current caller’s scope, then retain only inputs whose conversion lifetime spans ordinary messages. A parameter whose shape cannot be captured disables reuse without changing the original analysis’s result or diagnostic order.
analyze_plan_result: Analyze a statement in one binding scope, retain input-function results in its executable tree and derive its result without running statement expressions.
analyze_procedural_plan: Analyze a reached SQL occurrence once in its retained catalog scope. CALL resolves and converts its selected inputs before successful publication too.