Issue #87 established the pattern: enrich the SQLite view to full column parity, then delete the Rust handler and its interception branch, so SQLite executes joins, WHERE, regex, and projection.
src/catalog/ is ~9,300 lines of hand-rolled query engine over relations that mostly already exist as views. Each remaining handler is a source of silent wrong-answer bugs of the kind #87 documented — a gap in the reimplementation returns wrong rows rather than an error.
Suggested order, most-used first: pg_attribute, pg_proc, pg_description, pg_roles/pg_user, pg_stats.
Prerequisite for handlers whose views do not yet exist: create the view first. pg_stats and pg_tablespace in particular have no SQLite view today (migrations v19 and v24 say so explicitly).
See docs/superpowers/specs/2026-08-10-pg-class-sqlite-engine-design.md for the design and the rejected alternatives.
Issue #87 established the pattern: enrich the SQLite view to full column parity, then delete the Rust handler and its interception branch, so SQLite executes joins, WHERE, regex, and projection.
src/catalog/is ~9,300 lines of hand-rolled query engine over relations that mostly already exist as views. Each remaining handler is a source of silent wrong-answer bugs of the kind #87 documented — a gap in the reimplementation returns wrong rows rather than an error.Suggested order, most-used first:
pg_attribute,pg_proc,pg_description,pg_roles/pg_user,pg_stats.Prerequisite for handlers whose views do not yet exist: create the view first.
pg_statsandpg_tablespacein particular have no SQLite view today (migrations v19 and v24 say so explicitly).See
docs/superpowers/specs/2026-08-10-pg-class-sqlite-engine-design.mdfor the design and the rejected alternatives.