warn-set-schema

What It Detects

ALTER ... SET SCHEMA breaks every schema-qualified reference to the object and changes how unqualified ones resolve.

Why It's Dangerous

Moving an object between schemas is a rename in every way that matters, and it takes effect all at once — every query naming it as old_schema.thing starts failing the instant the migration commits. There is no deprecation window, and old and new application versions overlap during a rolling restart. Unqualified references are the more insidious half: they resolve through search_path, which is per-role, so whether they still work depends on who is asking. Your psql session looks fine while the application role is broken.

Bad Example

ALTER TABLE users SET SCHEMA archive;
-- Every "public.users" reference breaks at commit

Good Example

-- Leave the table where it is and expose it at the new path, so both
-- paths work while the application migrates. Move it for real in a
-- later migration, once nothing references the old one.
CREATE VIEW archive.users AS SELECT * FROM public.users;

Configuration

Disable this rule:

# .migrationpilotrc.yml
rules:
  MP098: false

Or change its severity:

# .migrationpilotrc.yml
rules:
  MP098:
    severity: warning