Verify and document pg_dump schema snapshot input

[omer-cengel]

Summary

A service that does not keep its schema as SQL migrations, such as one using a Liquibase changelog or a JPA-generated schema, can point sqlcj at a pg_dump --schema-only file. This change adds a reference service and a PostgreSQL integration test showing that its migration history, an equivalent hand-written snapshot, and a live pg_dump of the migrated database generate the same compiling, executable Java. It also documents the dump as a supported schema input.

Changes

• Add a reference service under the CLI test resources: ten migrations covering organizations, users, projects, tasks, comments, time entries, an audit log, views, a second schema, row-level security, an enum replacement, a LIKE copy and partitions, plus an equivalent hand-written snapshot and a query group over its tables.
• Add ReferenceServiceIntegrationTest, which:
  • applies the history to PostgreSQL 16 with psql and runs pg_dump --schema-only against the migrated database,
  • asserts that the history, the snapshot and the dump generate one byte-identical, compiling output tree, manifest included,
  • executes the generated repository against the migrated database,
  • asserts the located diagnostic for an unsupported ALTER COLUMN ... SET DATA TYPE migration and the unknown-table diagnostic for a query naming a table of another schema, neither writing any file.
• Document a pg_dump --schema-only snapshot as a schema file in the configuration reference.
• In the PostgreSQL guide, document:
  • what a dump contains that sqlcj ignores, including meta-command lines, the SET preamble, identity and sequence statements, constraints, grants and other schemas,
  • how a dump writes partitions and public. qualification,
  • that a dump matches a migration history only when the history changes the schema through statements sqlcj reads.
• List the new tests under "Verified by".

Scope and non-goals

• No production code changes. Generated code, the CLI and the configuration format are unchanged.
• The dump is produced at test time and not committed, because each pg_dump run writes a new \restrict key.
• ALTER COLUMN ... SET DATA TYPE remains unsupported and is rejected with its location.
• DDL inside DO blocks or function bodies, and columns removed by DROP TYPE ... CASCADE, are still not read from a migration history. The documentation names them as the cases where a dump and its history differ.