Module ddl 

DDL semantics (D4): protection modelling and absent-target preflight.

DDL in MySQL/MariaDB commonly performs an implicit commit, so a preceding backup transaction cannot be atomic with the DDL itself. DDL protection is therefore modelled as a durable pre-operation snapshot with explicit nontransactional warnings — never as transactional DML protection. Absent targets are resolved by preflight (existence checked with bound parameters) instead of converting ER_NO_SUCH_TABLE at backup time into “empty backup, proceed”.

Enums

DdlPreflight

Result of checking DDL targets for existence before execution.

DdlPreflightError

ProtectionModel

How a statement’s backup/protection guarantee is modelled.

Functions

preflight_ddl

Check every mutated table of a DDL statement for existence using information_schema.tables with bound parameters. fallback_db resolves unqualified names (connection default).

protection_model_for

Map a classified statement to its protection model. DDL categories get snapshot semantics; writes get transactional semantics when a backup is captured (or none is required); everything else is by definition not a mutation.

rewrite_drop_subset

Build the fail-closed rewrite of a Mixed multi-target DROP: only the preflight-approved existing targets, fully qualified, backtick-escaped, with IF EXISTS retained. Returns None for object types whose drop cannot be safely reconstructed (DROP INDEX and friends) — the caller fails closed in that case. This closes the plan→execute TOCTOU: a table created after the preflight is not named by the rewritten statement, so it cannot be dropped without a fresh plan and approval.