test(conformance): see object kinds, and cover creating them from nothing - #195

…hing

The suite verified diff -> apply -> compare, which is the right shape, but two
gaps meant whole classes of defect could not fail it.

**The fingerprint could not see most of a schema.** It compared columns,
constraints and indexes only. A partitioned table and an ordinary one are
indistinguishable in information_schema, which is how a migration that silently
flattened partitioning passed. It now also reads relkind and relpartbound,
views, triggers, routines, types with their enum labels, policies and sequence
parameters — the catalog, not the view over it.

Turning that on immediately failed 12 previously-green patterns. They are real:
for a column declared GENERATED BY DEFAULT AS IDENTITY with INCREMENT 10,
DBDiff emits only ALTER COLUMN ... TYPE integer and the identity is dropped
entirely. The old fingerprint could not notice because identity columns carry
no column_default.

**Every extracted pattern is an ALTER.** extract-patterns.php classifies
ALTER TABLE statements and explicitly skips PARTITION, INHERITS and REFERENCES,
so before_sql always creates a table and alter_sql mutates it. Nothing ever
built an object from nothing — which is precisely where the primary-key, serial,
enum and partitioning defects lived.

patterns-objects.json adds 20 hand-authored patterns with empty before_sql,
covering creation of tables with keys, serial and identity columns, enum,
composite and domain types, range and list partitioning, indexes on partitioned
parents, views, materialised views, functions, triggers (including on a
partitioned parent), policies, sequences, foreign keys between two new tables,
and generated columns.

14 pass. The 6 that do not are recorded, and the distinction between them
matters more than the count:

  - 5 are unmodelled kinds — composite types, domains, materialised views,
    policies and standalone sequences produce NO diff at all while the schemas
    genuinely differ. A user sees "no drift" and believes their environments
    match. That is the more dangerous class.
  - 1 is wrong output — identity with non-default sequence options.

known-failures.json baselines all 18 by id and separates the two classes, so
the suite fails on new regressions rather than on this backlog. An entry that
starts passing is reported too, so the list cannot rot.

Also guards PDO::exec against an empty before_sql, which a create-from-nothing
pattern legitimately has.

Postgres suite 47 tests; unit + SQLite 334 tests.

Co-Authored-By: Claude <noreply@anthropic.com>

An identity column carries a sequence, and that sequence's options are part
of the column definition. The adapter read `is_identity` and
`identity_generation` but none of `identity_start`, `identity_increment`,
`identity_maximum`, `identity_minimum` or `identity_cycle`, so

    id bigint GENERATED ALWAYS AS IDENTITY (INCREMENT 10 START 100)

was recreated as a plain identity counting up from one by one. The DDL
applies cleanly and the column looks right, so nothing fails — the next
insert just collides with rows the migration was meant to preserve.

Only non-default options are emitted. The defaults depend on the column's
type, and MAXVALUE for an `integer` identity is not the MAXVALUE for a
`bigint` one, so spelling out an inherited default would make every identity
type change read as two differences. Bounds are written out as literals
rather than computed: bigint's floor overflows a native PHP integer and
bcmath is not a dependency.

This was the single root cause behind every `wrong_output` entry in the
conformance baseline — 13 of them, including cases filed under alter_table
and change_type that did not look identity-related. `wrong_output` is now
empty and those entries are removed; the 5 remaining known failures are all
`unmodelled_kind` (composite types, domains, policies, sequences, matviews).

Verified against live PostgreSQL 16, 17 and 18: conformance exits 0 on all
three, mismatches 0. Full suite re-run — Unit 749, MySQL 17, Postgres 47,
SQLite 16 — since the bulk column query is shared and a change there is not
self-evidently Postgres-only.

Co-Authored-By: Claude <noreply@anthropic.com>