Struct AlterTableExecutor 

pub struct AlterTableExecutor;

Executor for ALTER TABLE statements

Implementations

impl AlterTableExecutor

pub fn execute( stmt: &AlterTableStmt, database: &mut Database, ) -> Result<String, ExecutorError>

Execute an ALTER TABLE statement.

Convenience wrapper over execute_with_source for callers that do not have the original statement text (e.g. an AST built programmatically). Without the source text, ADD COLUMN falls back to reconstructing sqlite_master.sql from the schema rather than editing the verbatim text in place. See issue #5625.

pub fn execute_with_source( stmt: &AlterTableStmt, database: &mut Database, alter_sql: Option<&str>, ) -> Result<String, ExecutorError>

Execute an ALTER TABLE statement, optionally given the verbatim original statement text (alter_sql).

After a successful structural ALTER, two pieces of bookkeeping run (issue #5625):

1. Catalog schema sync. Column operations (ADD/DROP/RENAME/MODIFY) only mutate the storage Table copy of the schema. The catalog copy — read by sqlite_master, PRAGMA table_info, and DML column resolution — is then re-synced from the storage copy so both stay consistent. (RENAME TABLE syncs via drop+create and is exempt.)

2. sql_source upkeep. SQLite edits the verbatim CREATE TABLE text in sqlite_master.sql in place on ALTER rather than reconstructing it. For ADD COLUMN, RENAME COLUMN, DROP COLUMN, and RENAME TO the stored verbatim text is edited to match SQLite (when alter_sql is available / the structure permits; RENAME TO is handled in table_options::execute_rename_table). For the remaining variants, and whenever an in-place edit cannot apply cleanly, the stale text is invalidated so it is reconstructed from the (now-synced) schema. Either way the stored text remains re-parseable on reload (issue #5619).