[jbylund]

Closes #128. Stacked on #138, which is stacked on #137 — this PR targets #138's branch, so the diff here is only the unique-constraint work.

Table takes unique, any number of keys spelled the way primary_key is:

Table("users", {"id": "integer", "email": "text", "tenant": "text"},
      primary_key="id", unique=["email", ("tenant", "email")])

Output is byte-identical to PostgreSQL 18 for the same declaration, ordering included — psql sorts the footer indisprimary DESC, relname:

Indexes:
    "u1_pkey" PRIMARY KEY, btree (id)
    "u1_a_b_key" UNIQUE CONSTRAINT, btree (a, b)
    "u1_email_key" UNIQUE CONSTRAINT, btree (email)
    "u1_oddName_key" UNIQUE CONSTRAINT, btree ("oddName")

Most of the diff is undoing a one-key-per-table assumption

#128 was supposed to be small, and the declaration half was. The catalog half was not, because #127 had baked in "at most one key per table" in two places:

• Index and constraint OIDs came from the table's position (_FIRST_INDEX_OID + index), so a table with three unique constraints would have issued three rows sharing one OID.
• The row builder was a single if table.primary_key: block.

Both are now driven by a running count over the rows actually emitted. Worth knowing for #129, which adds a third kind of constraint to the same loop.

Where the two kinds of key actually differ

They share one code path that branches in exactly three places, which is the useful summary:

	primary key	unique
contype / rendering	p / PRIMARY KEY (...)	u / UNIQUE (...)
indisprimary	true	false — psql reads this to pick the footer label
columns implicitly NOT NULL	yes	no

The third is the one substantive difference, and it has a test asserting \d u1 says not null exactly once.

Naming

Index names are relation names, so they are unique across the schema rather than per table, and generated the way Postgres generates them: t_pkey, or t_<columns>_key with the column names unquoted whatever they are — Postgres builds u1_oddName_key from "oddName" and quotes the whole name only when printing it.

Truncated to 63 bytes (NAMEDATALEN - 1), which is reachable with an ordinary long table name plus two columns, and a truncation that collides gets a counter as Postgres' own ChooseIndexName does. Identical keys are refused at declaration instead, since that is a copy-paste rather than a name clash.

Tests

18 new. test_declared.py for normalisation and the three refusals; test_pg_catalog.py running psql's footer query verbatim and asserting the full ordered row set, plus the truncation and OID-uniqueness cases; test_psql.py asserting all four rendered footer lines against the real binary.

Full suite: 946 passed, 32 xfailed (up from 928). ruff check and ruff format --check clean.

Not in scope

Foreign keys (#129) and declaring a constraint after construction (#130). Unique indexes that are not constraints — CREATE UNIQUE INDEX without ADD CONSTRAINT, which psql prints as UNIQUE, rather than UNIQUE CONSTRAINT, — have no declaration surface and nothing needs them.