[jasdeepkhalsa]

One commit per change, each with its own tests. Most came out of a smoke matrix: every pair of Supabase 15 and 17 and PostgreSQL 14–18, each way. Each pair ran a first sync, drift with live rows on the target (renames, a retype under a generated column and views, an enum label, --prove), and a snapshot and restore.

Commit	What it does
A revoke on an object the same apply drops is done	A view dropped by the schema fix took its grants with it. When the drop ran first, the roles check's revokes on it failed with does not exist and the run exited 1. Such a revoke now counts as applied, with a note. One whose object a later fix creates is still retried. Fixes #147.
Warn before a restore or apply needs more locks than the target has	The statements are counted (relations, indexes, TOAST and identity sequences) against the target's lock table, less what other sessions hold. When they look unlikely to fit, the run says so before starting, and names --no-transaction and max_locks_per_transaction as the ways round it.
Compare grants on schemas	USAGE on a schema of the project's own wasn't compared, so a target without it read as matching while its tables were out of the Data API's reach. PostgreSQL 15's change to the default CREATE on public isn't compared across that version boundary.
A snapshot keeps grants on schemas and default privileges	roles.sql held table, column and routine grants. Restore lost schema USAGE and every ALTER DEFAULT PRIVILEGES.
Leave out a fix an older target cannot parse	From a newer source, UNIQUE NULLS NOT DISTINCT on 14 or a VIRTUAL column on 17 failed with a syntax error and rolled back the whole apply. On an older target that fix is now left out and reported, and the rest applies. --prove rehearses it the same way.
Leave Supabase's own default privileges, and pgmq's tables, out of the schema check	supabase_admin's default privileges are the platform's, and postgres can't change them. pgmq's tables are compared by the queues check.
Offer only the extension changes the target can make	A version mismatch was always fixed with UPDATE TO the source's version, even downwards (pg_cron 1.6 against 1.6.4), which failed the apply. The target's update paths now decide. An extension in its own schema creates that schema first; plain PostgreSQL may lack extensions.
Restoring into an older server leaves out what it cannot hold	The same as the apply, for restore: the snapshot's version is read from pg_dump's header.
A scan reads each database as of one instant	The checks ran many concurrent queries, and a change made meanwhile was seen by some of them only. Each database is now read in one exported snapshot that every pooled connection joins, released before anything is applied. --no-snapshot reads query by query.
An extension in a system schema is created without making the schema	pg_cron lives in pg_catalog on Supabase, and CREATE SCHEMA "pg_catalog" is refused.
An extension the target does not ship is left out, schema and all	Once an extension's fix made its schema first, it no longer began with CREATE EXTENSION, and one the server doesn't ship (pg_graphql on plain PostgreSQL) failed the whole apply instead of being left out.
--prove matches a NOT NULL constraint by its column, not its name	On PostgreSQL 18 a NOT NULL is a named constraint, and a renamed table keeps its old names. Compared with the source's structure made fresh, a rename from an older source read as constraints missing, and the migration was refused.

Tests:

• New unit and e2e tests, including reads as of a held snapshot against a real server.
• The unit suite and lint pass.
• The release smoke battery passes.

🤖 Generated with Claude Code