ban-rename-in-use-column

What triggers it

A RenameStmt whose renameType is OBJECT_COLUMN (libpg-query returns this as the string 'OBJECT_COLUMN', or numerically 7) — ALTER TABLE ... RENAME COLUMN ... TO ....

What does not

Any other RenameStmt target (renaming a table, index, or constraint uses a different renameType), and any column rename where another statement in the same migration is a CREATE OR REPLACE VIEW or CREATE OR REPLACE FUNCTION whose SQL text mentions the new column name — the rule takes that as evidence the dependents were updated in the same migration.

Where it applies

Applies to every PostgreSQL version MigrationPilot targets. It works on the SQL text alone — no database connection needed.

The lock, and what it blocks

No lock is named in the source — the danger here isn't blocking, it's that views, functions, triggers, and policies referencing the old column name keep compiling against a name that no longer exists and fail the moment they're invoked.

Why it matters

PostgreSQL does not automatically update views, functions, triggers, or policies when a column is renamed. All dependent objects continue referencing the old name and fail at query time.

Unsafe, and safe

ALTER TABLE users RENAME COLUMN name TO full_name;

-- Safe add-copy-drop pattern:
ALTER TABLE users ADD COLUMN full_name TEXT;
UPDATE users SET full_name = name WHERE full_name IS NULL;
-- Update all views/functions, then drop old column

Deploy and transaction boundaries

Same expand-contract shape as MP010: add the new column, backfill data, deploy the application change that reads and writes the new name, and only then drop the old column in a later migration. The app deploy has to land between the backfill and the drop.

What it assumes

The dependents check is a same-migration text search for the new name inside a CREATE OR REPLACE VIEW/FUNCTION statement — it can't see application code, so a rename with no view or function update in the migration is flagged even when the app is genuinely unaffected, and a coincidental text match could just as easily suppress a real warning.

What backs this rule

Every rule is a claim about PostgreSQL, so it carries what the claim rests on: a handbook chapter that cites the manual, the incidents that put it there, and the version it was last checked against.

What the CLI prints

⚠ [MP071] WARNING (line 1)
  Renaming "name" to "full_name" on "users" will break any views, functions, or triggers referencing the old name. Use the add-copy-drop pattern instead.

  Safe alternative:
  -- Safe add-copy-drop pattern:
  -- Step 1: Add new column
  ALTER TABLE users ADD COLUMN full_name <type>;
  
  -- Step 2: Backfill data (batched for large tables)
  UPDATE users SET full_name = name WHERE full_name IS NULL;
  
  -- Step 3: Update all views, functions, triggers to use "full_name"
  
  -- Step 4: Drop old column in a separate migration
  ALTER TABLE users DROP COLUMN name;

  Why: PostgreSQL does not automatically update views, functions, triggers, or policies when a column is renamed. All dependent objects continue referencing the old name and fail at query time. The safe alternative is the add-copy-drop pattern: add a new column, backfill data, update all dependents, then drop the old column in a separate migration.
  Docs: https://migrationpilot.dev/rules/mp071

Generated by running the CLI's own formatter over the flagged example above, so it is the text the tool actually produces. A real run also reports the other rules that fire on the same statement; those blocks are left out here.

Turning it off

For one statement, put a comment on the line before it:

-- migrationpilot-disable MP071
ALTER TABLE users RENAME COLUMN name TO full_name;

For the whole project, in .migrationpilotrc.yml — by name or by id:

rules:
  MP071: false

# or keep it, and downgrade it
rules:
  MP071:
    severity: warning

Try it

Open this rule's flagged example in the playground. It runs in your browser — edit it and watch the finding appear and disappear.