fix: serve pg_class and pg_namespace from SQLite instead of Rust handlers (#87)

[erans]

Fixes #87

The bug

\dt reported "Did not find any tables" on a database that has tables. Three
mechanisms combined to turn one psql predicate into a universal row filter:

1. RegexTranslator runs before catalog interception and rewrites
   n.nspname !~ '^pg_toast' into NOT regexp('^pg_toast', n.nspname).
2. WhereEvaluator has no case for regexp(). Unknown functions fall through
   to true — "default to including the row".
3. NOT inverts that default into an exclusion. !true is false. Every row
   fails.

The dedicated PGRegexMatch/PGRegexNotMatch arms in WhereEvaluator are dead
code on this path — the operator is gone before the AST reaches them.

Two further defects sat behind it, so a narrow regex fix would not have worked:
PgClassHandler synthesized only its own columns, so the LEFT JOIN pg_namespace was never materialized and n.nspname evaluated to None
(\dt's n.nspname <> 'pg_catalog' passed only by accident, because
None != Some(..)); and joins were not executed at all.

The fix

Rather than patch the WHERE evaluator, delete the hand-rolled Rust handlers for
pg_class and pg_namespace and let SQLite execute those queries against real
views. Joins, WHERE, regexp(), ORDER BY, and projection all become the
engine's job. Migration v28 enriches the pg_class view from 25 to 33 columns
so nothing is lost, computing relnatts from pragma_table_info and
relhastriggers from sqlite_master rather than hardcoding them.

The alternative of bailing out of interception on hard queries was rejected: the
bail-list is itself a guess-list, and a query that succeeds while returning
wrong data never triggers a fallback. Deleting the handler leaves one code path
and no decision logic to drift — a missing column is now a loud SQLite error
rather than silent wrong rows.

Design: docs/superpowers/specs/2026-08-10-pg-class-sqlite-engine-design.md

Also fixed

Found while implementing; each was silently returning wrong answers.

• ~ was silently ignored on catalog tables, returning unfiltered results
  with no error.
• Cross-catalog joins through pg_class.oid never matched. pg_class
  served hash31 OIDs while pg_constraint, pg_index, pg_attrdef, and
  pg_depend persist unicode-formula OIDs. Measured on a fresh database:
  pg_class.oid(customers) = 197947 but pg_constraint.conrelid = 51945, so
  FK discovery — the first ORM example in CLAUDE.md — returned zero rows. Four
  different OID formulas existed; there is now one,
  crate::utils::generate_table_oid, which every producer delegates to.
• --in-memory catalog queries hard-errored. Migrations ran on a throwaway
  :memory: connection while each session opened its own private empty
  database. Now uses a shared-cache URI with a keepalive connection.
• \dt no longer lists pgsqlite's own pg_* relations, because v28 assigns
  them to the pg_catalog namespace (oid 11) and information_schema_* to a
  new information_schema namespace (oid 13000). No special-casing in
  pgsqlite — psql's own nspname predicate does the hiding.
• generate_table_oid and generate_oid overflowed u32 on a leading
  codepoint above 4294, panicking in debug builds and silently wrapping in
  release. Both now compute in u64.
• The Rust and SQL OID formulas were not the same function. Rust used
  name.len() (UTF-8 bytes); SQLite uses length() (characters). café
  produced 996619 in Rust and 996612 in SQL, so any non-ASCII table name got
  a pg_class.oid matching none of its persisted join keys. Every ASCII value
  is unchanged — customers is still 197947.

Three existing view bugs fixed in passing: relkind_full is not a real
PostgreSQL column (dropped), relreplident should be 'd' not 'v', and
relispartition should be 'f' not 't'.

Behavior changes worth knowing

• --in-memory sessions now share one database. Previously each session got
  its own (empty, unmigrated) one, which is why catalog queries failed. This is
  the fix, but it is a real semantic change.
• pg_class OIDs changed value from hash31 to the unicode formula. This
  removes an inconsistency — the new values are the ones the rest of the
  catalog already stored on disk — but any external tooling that memoized a
  pg_class OID will see it move.
• Non-ASCII table names get a new OID. Any such OID already persisted was
  written by the byte-counting version and will not match until a data
  migration. The prior state was already broken (view and persisted value
  disagreed), so this is a fix-forward.
• relhasindex is hardcoded 't' and relfilenode '0' in the view, where
  the deleted handler computed them from PRAGMA index_list and the oid. Both
  inherited from the v26 view and both fail safe.
• \dt now hides pgsqlite's internals while information_schema.tables still
  shows them — it builds its own row set with a hardcoded 'public'. That gap
  is information_schema.tables lists pgsqlite's materialized pg_* and information_schema_* relations #88.

Testing

1302 passed, 0 failed, 195 binaries. Baseline before this branch was 1296/194.

New coverage: psql's exact \dt query (asserting customers appears and
that pg_constraint/pg_attrdef/pg_index/pg_depend do not); ~ and !~
each pinned with a positive and a negative case so neither can pass vacuously;
pg_class JOIN pg_constraint ON conrelid = oid returning rows; all 33 columns
selectable with relnatts matching real column counts; the OID formula pinned
against values computed independently through the sqlite3 CLI; and cross-session
pg_class visibility on the in-memory URI.

\dt was also verified end-to-end through real psql 18 against the built binary.

Follow-ups filed

#93 OID collisions · #94 WhereEvaluator unknown-predicate-under-NOT ·
#95 migrate the remaining catalog handlers · #96 JOIN routing bypassed by the
system-function gate · #97 pooling path registers no UDFs · #98
obj_description() can never match · #99 regclass non-canonical OID ·
#100 PgAttributeHandler missing COUNT(*)

🤖 Generated with Claude Code