To rename a column safely, and to change its type without a long lock, takes more than one ALTER TABLE. FoxSchema's Rename Column utility first shows everything that depends on the column, then turns a type change into three parts you can read, copy or run.
How to rename a column safely: start with what it touches
Open Utils → Rename Column, choose a connection, then a table and a column, and enter a new name, a new type, or both. Before any SQL appears, FoxSchema lists what the column touches in the schema it already loaded: indexes, unique constraints, outbound foreign keys, triggers, functions, procedures, and views whose definition may mention it. The view, function and procedure checks are a text match, so treat them as a prompt to look, not a guarantee.
A rename is one statement
If you only change the name, FoxSchema emits a single instant RENAME COLUMN (or sp_rename on SQL Server). Nothing is copied. You still need to update application code and any view or routine the touches list flagged.
A type change runs in three parts
Changing the type follows the expand-contract idea: add the new column beside the old one, move the data, then switch over. Each part has preview SQL you can Copy or Run from the screen, and Safe mode asks you to confirm:
- Add a nullable column with no default.
- Copy the rows in a loop of batches, with progress shown as copied / total. The Rows per batch field sets the size; the default is 10,000.
- Constraints, triggers and description: indexes, keys, the catalog comment and table triggers are rewritten for the new column, then the switch-over happens and the old column is dropped.
Execute all runs the three parts in order against this connection. Copy all and Open in editor send the whole script to a new editor tab instead.
Warnings when you rename a column safely
- Lossy conversions (a smaller type, text to number, text to boolean) show a warning you must acknowledge before Run or Execute all. The copy still stops on the first value that does not convert, so test with real data on staging.
- MySQL and SQL Server need both sides of a foreign key to have the same type; the planner refuses and names the parent column when they would not.
- CockroachDB and TiDB have no copy trigger, so pause writes or run the copy once more before the last part.
Where it works, and where it says "not yet"
Safe column change is available for PostgreSQL, YugabyteDB, CockroachDB, MySQL, MariaDB, TiDB, SQL Server and Azure SQL. SQLite (which needs a table rebuild), Redshift, Oracle and Db2 say "not yet" rather than produce SQL that would fail there. FoxSchema also refuses, for now, a primary-key column, a column that other tables' foreign keys point at, an identity column, and a type change on a table with no primary key, because the copy batches through the key.
Why three parts instead of one
A single in-place type change can rewrite the whole table under a lock. Splitting it lets the slow part, the copy, run in batches while the old column keeps serving traffic. The idea is the same one described in our guide to the expand-contract migration pattern and in zero-downtime schema migrations; Rename Column just writes the steps for you and shows what they affect.
See the Feature Guide for the full Utilities walkthrough. Install FoxSchema or self-host it with Docker to try it on your own databases.
Further reading: for more on rename a column safely, see the PostgreSQL ALTER TABLE guide.
