Schema Diff: make the regression test assert its generated script, and fix what that found

[dpage]

What this is

SchemaDiffTestCase wrapped applying its generated script, and the comparison that follows, in a bare except Exception that discarded both, so it reported a pass whatever the script did. That is why --pkg tools.schema_diff has been printing

syntax error at or near ")"
LINE 995: );

on every run whilst cheerfully reporting 2 tests passed. This makes the test assert what it was written to assert, and fixes the bugs that turning it on exposed. Each of those is filed separately, and the commit message maps them one to one.

The test

It now fails when an object's SQL does not apply, and when applying the whole script leaves the two databases different. Two differences it cannot settle yet are listed in KNOWN_DIFFERENCES with their issue numbers, and the test also fails if one of them starts passing, so the list cannot quietly rot.

Objects go in one at a time and are retried, rather than as a single script, because the script is no longer ordered by dependency (#10295), so an object can fail purely because something it needs comes later on. Retrying tells that apart from SQL that is simply wrong. When #10295 is fixed this can go back to applying the script in one go.

restore_schema() now returns the error alongside its status, so a failure says which statement did not apply, and the script is left on disk when the test fails since it is the only evidence of what went wrong.

The fixes

• Schema Diff: recreating a range type as part of a kind change generates CREATE TYPE ... AS RANGE () #10304 — a range type dropped and recreated because its kind changed lost its subtype, because directory_diff() drops a plain value that only one side of the comparison has, and rendered CREATE TYPE ... AS RANGE (). With that fixed it wrote the catalogue's - placeholder out as CANONICAL = -; the reverse-engineered SQL path already maps - to None, and the comparison path now does too.
• Internal objects — the constructor functions, casts and multirange types PostgreSQL creates for a range type were compared as though a user had written them, so the script tried to recreate objects that come into being with their parent. That was 47 of the 151 objects in the fixtures. Internal dependencies are now excluded alongside extension ones, which is what pg_dump does. Note this is on the schema-diff queries only; the object explorer still lists them, which is worth its own look.
• Schema Diff: recreating a foreign table duplicates any column that also differs #10297 — recreating a foreign table declared any column that also differed twice, because a changed column was appended to the table's existing columns rather than replacing the entry already there.
• Schema Diff: raising a sequence's MINVALUE above its current value generates SQL that PostgreSQL rejects #10298 — raising a sequence's MINVALUE above the value it currently sits at, or lowering MAXVALUE below it, generated a statement PostgreSQL rejects outright, taking every other change to that sequence with it. Such a change now carries the RESTART it requires; a sequence already within its new bounds is left where it is.
• Schema Diff: a foreign table column added by Schema Diff loses its collation #10300 — a foreign table column added by Schema Diff lost its collation, because get_columns.sql calls it collname whilst the column templates render collspcname.
• Schema Diff: a comparison that fails part way through is also reported as successful #10303 — a comparison that threw part way through emitted its failure and then reported success as well, handing the client a fraction of the databases as though it were complete. This is how a 42-object partial comparison passed for a 151-object one whilst I was working on this.

Still open

table table_for_partition_1 (#10301, the rebuild keeps its scaffolding default partition) and procedure proc1 (#10302, CREATE OR REPLACE wraps the body in newlines) are the two known differences. #10292 and #10295 are untouched and described on their own issues; #10295 in particular means users' generated scripts can fail to run, and wants JS work.

Testing

tools.schema_diff (3), resql, foreign_tables (44), sequences (11), types (39), functions (74), casts (38) and tables (469) all pass against PostgreSQL 18, and pycodestyle --config=.pycodestyle is clean. I confirmed the new assertions bite by watching them fail on each bug in turn before fixing it.

[coderabbitai]

Caution

Review failed

An error occurred during the review process. Please try again later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}