fix(pg_introspect): read FKs from pg_constraint so read-only roles get 'references' edges (#1746)

[rithyKabir]

Fixes #1746.

Root cause

introspect_postgres reads foreign keys from information_schema.referential_constraints — but per the PostgreSQL docs:

Only those constraints are shown for which the current user has write access to the referencing table (by way of being the owner or having some privilege other than SELECT).

A read-only introspection role — exactly what hosted providers like Supabase hand out, and what pg_introspect's own READ ONLY transaction encourages — therefore gets zero FK rows, while tables/views/routines all still appear (SELECT is enough for those views). The graph then builds "successfully" with contains/reads_from edges but not a single references edge, matching the reported counts (459 contains + 183 reads_from, 0 references). This is also why file-based extraction of the same schema's migrations does produce references edges — the gap is specific to the live-introspection path.

Reproduced live on PostgreSQL 16 with a SELECT-only role: referential_constraints → 0 rows; pg_catalog.pg_constraint (contype='f') → all 3.

Fix

Query pg_catalog.pg_constraint instead — system catalogs are not privilege-filtered. The query returns the same 7-column shape, so DDL generation is untouched.

This also fixes a latent second bug: PostgreSQL constraint names are only unique per table, and the old name-based key_column_usage joins cross-matched same-named constraints on sibling tables. Verified live: two tables each with a constraint named fk_owner produced columns = {user_id,user_id,user_id,user_id} (malformed FK DDL) even for a privileged user. pg_constraint keys by oid, and unnest(conkey) WITH ORDINALITY preserves composite-FK column order.

Verification

• Live PostgreSQL 16 (Docker), schema with a single-column FK, a composite FK, and same-named fk_owner constraints on two sibling tables, introspected as a SELECT-only role: all 3 references edges emitted end-to-end, composite FK produces exactly one edge, both fk_owner FKs attributed to the correct tables.
• New regression test asserts the FK query no longer touches referential_constraints and still yields the references edge; the test mock now records executed queries.
• tests/test_pg_introspect.py 7/7, plus test_extract.py + test_multilang.py (172 total) green; ruff clean.

🤖 Generated with Claude Code

[safishamsi]

Merged on v8, authored to you. The root cause is exactly right: information_schema.referential_constraints is privilege-filtered to write-access roles, so a read-only introspection role sees tables/views (SELECT suffices) but zero FKs — silent loss of every references edge. Switching to pg_catalog.pg_constraint (world-readable) is the correct fix, and keying by oid instead of constraint name also closes the same-named-constraint-on-sibling-tables cross-match in the old joins. UNNEST ... WITH ORDINALITY correctly preserves composite-FK column order. Mock tests pass (7) and full suite green (3139). I couldn't run it against a live Postgres here, but the catalog query is standard and the mock coverage + review cover it. Thanks for the sharp diagnosis.