fix: namespace-aware information_schema served from SQLite (#88)

[erans]

Fixes #88.

Problem

information_schema.tables reported pgsqlite's own materialized catalog relations as user tables in public:

public|pg_am
public|pg_class
public|information_schema_tables
...
public|customers

28 internal relations alongside the one real table, so Django inspectdb and SQLAlchemy automap would generate models for pg_constraint and friends.

Real PostgreSQL returns these rows too — a stock cluster has ~180 — but under table_schema = 'pg_catalog' / 'information_schema'. Clients filter on table_schema; that filtering is the mechanism that hides them, not omission. So the fix reports the correct schema rather than hiding the rows.

Root cause

Not the line the issue cited (query_interceptor.rs:2059 is inside the columns handler). The live path was handle_information_schema_tables_query, which ran

db.query("SELECT name, type FROM sqlite_master WHERE type IN ('table','view') \
          AND name NOT LIKE 'sqlite_%' AND name NOT LIKE '__pgsqlite_%'")

with no catalog filtering, emitting "public" for every row. Migration v28 (#87) had already assigned these relations to namespace 11/13000 in pg_class — which is why \dt was clean — but the information_schema_tables view hardcoded 'public' as table_schema and the Rust handler bypassed both.

The handlers were stale in the same way #87 found in PgClassHandler. Measured before this change:

Query	Result
SELECT table_name FROM information_schema.tables ORDER BY 1	29 rows, unsorted — ORDER BY ignored
SELECT count(*) FROM information_schema.tables	0 rows — aggregates unsupported
SELECT DISTINCT table_name FROM information_schema.columns	60 rows, DISTINCT ignored

WHERE support extended only to equality on table_name; every other predicate was silently dropped rather than erroring. Any fix that kept the handler would inherit all of it.

Approach

Follows the #87 precedent: make the SQLite views the single source of truth, delete the Rust handlers, and identify internal relations by exact name rather than by prefix.

Prefix matching is not sufficient in either direction. LIKE 'pg\_%' would misfile a legitimate user table named pg_myreport into pg_catalog — hiding it from ORM introspection, a regression on current behavior where it is at least visible. It also under-matches: eight migration-created idx_* indexes match no pg_% or __pgsqlite_% filter at all.

• src/catalog/internal_relations.rs — const registry of the 36 relations pgsqlite's migrations create, each tagged with its namespace OID, exposed as the __pgsqlite_relnamespace UDF. Returns 2200 (public) for anything unlisted — the safe direction, since the failure mode is showing an internal relation rather than hiding a user's.
• src/catalog/column_type_info.rs — pg_column_info() plus four UDFs. The deleted handler resolved character_maximum_length / numeric_precision / numeric_scale privately; all three were NULL in the view, so deleting the handler without replacing them would have regressed VARCHAR(50) to no length and NUMERIC(10,2) to no precision. Derived from the type string rather than an OID, since an OID cannot carry the (50) or (10,2) modifier.
• Migration v29 — rebuilds both views. information_schema_columns is built directly on sqlite_master / pragma_table_info / __pgsqlite_schema rather than layering on pg_attribute, which keeps it off a view every ORM reads for column reflection.
• Routing — SchemaPrefixTranslator rewrites both relations to their views; the stale handlers and their helpers are deleted.

Type fidelity

Routing columns to the old view as-is would have regressed six of eight columns. Measured on CREATE TABLE fidelity (id SERIAL PRIMARY KEY, amount NUMERIC(10,2), uid UUID, doc JSONB, tags TEXT[], ts TIMESTAMPTZ, flag BOOLEAN, nick VARCHAR(50)):

column	declared	old handler	old view	now
id	SERIAL	text ✗	integer ✓	integer
amount	NUMERIC(10,2)	numeric ✓	text ✗	numeric
uid	UUID	uuid ✓	text ✗	uuid
doc	JSONB	jsonb ✓	text ✗	jsonb
tags	TEXT[]	text ✗	text ✗	ARRAY
ts	TIMESTAMPTZ	text ✗	integer ✗✗	timestamp with time zone
flag	BOOLEAN	boolean ✓	integer ✗	boolean
nick	VARCHAR(50)	character varying ✓	text ✗	character varying

The old view leaking integer for TIMESTAMPTZ would have exposed pgsqlite's INTERNAL datetime storage on a client-visible surface.

Also fixed here

Two defects found by review while routing the queries through the translator:

• String literals were being corrupted. The prefix rewrite used blind String::replace, so SELECT 'information_schema.tables' came back mangled and WHERE msg = 'see pg_catalog.pg_class' silently stopped matching stored rows — breaking any table that stores SQL text (audit logs, migration history, docs tables). This predates the branch; it already affected the pg_catalog. rewrites shipped in \dt reports "Did not find any tables" on a database that has tables #87.
• Mixed-case qualifiers. The interceptor's gate is case-insensitive but the rewrites were not, so Information_Schema.Tables and INFORMATION_SCHEMA.tables — a spelling JDBC-derived tooling emits — hard-errored with no such table.

Both are closed by replace_outside_literals: case-insensitive, single left-to-right scan, skips '...' literals (with the doubled-quote escape) and "..." quoted identifiers. It is applied to the pg_catalog. rewrites too. Verified linear (2.69 MB query → 189 ms) and fuzzed against multi-byte UTF-8 at every character position; the byte/char-boundary hazard is designed out by comparing in place with eq_ignore_ascii_case instead of building a lowercased copy.

numeric_precision_radix also now reports 2 for binary-precision types and 10 only for numeric/decimal, matching _pg_numeric_precision_radix().

Testing

1341 passed / 0 failed. cargo check and cargo clippy warning counts unchanged from baseline (8 / 46).

New coverage in tests/information_schema_namespace_test.rs (13 tests): the #88 regression itself, the four handler defects above, the eight-column type-fidelity table, the four recovered columns, mixed-case routing, literal preservation, and numeric_precision_radix.

The drift guard (internal_relation_list_matches_migrated_database) compares the Rust registry against what a migrated-to-head database actually contains, in both directions, so a future migration that adds a catalog relation without updating the list fails loudly instead of silently leaking it. Proven non-vacuous during review by removing one entry and confirming the expected failure.

information_schema_test.rs and information_schema_comprehensive_test.rs are unmodified and still pass.

The SQLAlchemy suite could not be run: tests/python/run_sqlalchemy_tests.sh aborts because Poetry 2.4.1 rejects the virtualenvs.prefer-active-python key it sets. Pre-existing (introduced in 2482469, #53), unrelated to these changes.

Deliberately out of scope

pg_class keeps v28's LIKE 'pg\_%' heuristic and pg_attribute.atttypid is still derived from the SQLite declared type — both tracked in #102. Splitting them keeps this change off the path of \dt, \di, and every ORM introspection query one week after #87 landed there; the registry introduced here makes that follow-up a one-expression swap.

The consequence is a known divergence: a user table named pg_myreport reports public in information_schema.tables but is still misfiled under pg_catalog in pg_class. user_table_named_like_a_catalog_relation_is_visible asserts both, deliberately, so the gap is documented in a test rather than in a comment. That assertion flips when #102 lands.

🤖 Generated with Claude Code