Part of the Phase 2 set of PostgreSQL-specific features beyond the built-in driver.
Problem
Four RPC methods are already registered in rpc.rs's dispatch table but stubbed with not_implemented() in src/handlers/metadata.rs, returning a -32601 error instead of real data:
get_schema_snapshot
get_all_columns_batch
get_all_foreign_keys_batch
get_materialized_view_definition
Found during a README audit (2026-08-18) and surfaced in the README's "Known Limitations" section pointing back here.
Why this differs from the other Phase 2 items
Every other Phase 2 issue (#25–#31) is new-feature design work — deciding what the feature should even look like. This is different: the RPC surface and method names already exist in the dispatch table, so this is implementation work against an already-agreed contract, not feature design.
Proposed approach
get_materialized_view_definition — low-effort. Same pattern as the existing get_view_definition, reading from pg_matviews.definition.
get_all_columns_batch, get_all_foreign_keys_batch, get_schema_snapshot — need a host-side caller check first. There's no existing caller in this repo to infer the expected response shape from, so confirm what tabularis's frontend actually expects (likely a batched/aggregated response across multiple tables, given the naming) before implementing — check tabularis's frontend source for any code that calls these method names, or ask the maintainers if the contract isn't otherwise discoverable.
Acceptance criteria
References
- Priority: Sprint 7 — low effort, already-agreed contract
Part of the Phase 2 set of PostgreSQL-specific features beyond the built-in driver.
Problem
Four RPC methods are already registered in
rpc.rs's dispatch table but stubbed withnot_implemented()insrc/handlers/metadata.rs, returning a-32601error instead of real data:get_schema_snapshotget_all_columns_batchget_all_foreign_keys_batchget_materialized_view_definitionFound during a README audit (2026-08-18) and surfaced in the README's "Known Limitations" section pointing back here.
Why this differs from the other Phase 2 items
Every other Phase 2 issue (#25–#31) is new-feature design work — deciding what the feature should even look like. This is different: the RPC surface and method names already exist in the dispatch table, so this is implementation work against an already-agreed contract, not feature design.
Proposed approach
get_materialized_view_definition— low-effort. Same pattern as the existingget_view_definition, reading frompg_matviews.definition.get_all_columns_batch,get_all_foreign_keys_batch,get_schema_snapshot— need a host-side caller check first. There's no existing caller in this repo to infer the expected response shape from, so confirm whattabularis's frontend actually expects (likely a batched/aggregated response across multiple tables, given the naming) before implementing — checktabularis's frontend source for any code that calls these method names, or ask the maintainers if the contract isn't otherwise discoverable.Acceptance criteria
-32601errorsget_materialized_view_definitionmatchesget_view_definition's existing response shape/conventions*_batchmethods andget_schema_snapshotmatch whatever shape the frontend caller actually expects (verified against real caller code, not guessed)References