Phase 2: PostgreSQL-specific features beyond the built-in driver (tabularis#16)

[aesslinger]

Summary

Phase 2 of the postgres-plugin migration (referenced from tabularis PR #577, full plan in docs/planning/03-phase-2-issue-16.md). Where Phase 1 was byte-for-byte parity with the built-in driver, Phase 2 is where the plugin exceeds it — implementing PostgreSQL-specific features the built-in driver never had, tracked upstream as tabularis#16 ("Better PostgreSQL Support": schema handling, specialized data types, sequences, materialized views, etc.).

This issue is the tracking epic; each feature below has its own dedicated issue with the full spec, SQL, and test list. docs/planning/03-phase-2-issue-16.md remains the detailed design doc backing all of them.

Prerequisite: Phase 1 fully complete. 1.0.0-beta.8 is out, 82/82 parity. All Phase 1 sign-off items are done — confirmed via tabularis PR #577's sign-off checklist (security audit, CI hardening, cross-platform build, 24-item manual smoke test, and pnpm test/cargo test regression, all ✅, merged into Tabularis 0.20.0 on 2026-08-18).

Currently in the post-CP-4 stabilization window (per docs/planning/02-phase-1-plugin-build.md): baking on the beta channel against Tabularis 0.20.0+ until no new correctness bugs surface, then shipping 1.0.0 stable — independent of Phase 2 scope. Phase 2 sprints below have not started yet.

Note on scope vs. the original plan: two items from #16's description are already resolved and NOT part of this issue:

• Non-public schema browsing (tabularis#15) — already implemented (get_schemas, schema-qualified queries throughout src/handlers/metadata.rs).
• HStore column editing — tabularis#427 merged upstream 2026-08-02. Ported into Phase 2.3: Extension-aware type system #27 (extension-aware types) rather than reimplemented.

Before implementing any feature below, check tabularis for in-flight PRs that already address it (gh pr list --repo TabularisDB/tabularis --search "<feature>") — avoid duplicating community work. Known relevant PRs as of this writing:

PR	Feature	Status
#402	Multi-database connections	Open
#222	Composite PK end-to-end	Open (draft)

Features

• Phase 2.1: Sequence management #25 — 2.1: Sequence management (Sprint 1 — high demand, straightforward)
• Phase 2.2: JSONB inline editing #26 — 2.2: JSONB inline editing (Sprint 2 — high demand, UI extension)
• Phase 2.3: Extension-aware type system #27 — 2.3: Extension-aware type system (Sprint 3 — high demand for PostGIS/pgvector)
• Phase 2.4: Partition table introspection #28 — 2.4: Partition table introspection (Sprint 4 — medium demand)
• Phase 2.5: Row-level security policy visibility #29 — 2.5: Row-level security policy visibility (Sprint 5 — medium demand)
• Phase 2.6: Publication/subscription visibility #30 — 2.6: Publication/subscription visibility (Sprint 6 — lower priority)
• Phase 2.7: Advisory lock monitoring #31 — 2.7: Advisory lock monitoring (Sprint 6 — lower priority)
• Phase 2.8: Wire up stubbed batch/snapshot RPC methods #32 — 2.8: Wire up stubbed batch/snapshot RPC methods (Sprint 7 — low effort, already-agreed contract)

Approach

Same TDD discipline as Phase 1: write the test (RED) → implement (GREEN) → verify no regressions. Phase 2 features are plugin-only — they don't exist in the built-in driver, so there's no parity suite to satisfy; each feature gets its own dedicated tests instead.

Checkpoint: CP-5 (Phase 2 complete — feature-completeness milestone)

Versioning note: 1.0.0 stable ships at the end of Phase 1 stabilization (see above), not at Phase 2 completion. CP-5 below is a feature-completeness milestone on top of an already-stable 1.x release — each Phase 2 feature versions as a normal feat: minor bump per the README's PR-title → semver mapping, not a second "promote to stable" event.

This is a milestone worth communicating — the plugin becomes strictly better than the built-in driver, not just at parity with it.

• All Phase 1 parity tests still GREEN (no regressions)
• New Phase 2 features have dedicated tests (all GREEN)
• Sequence management works end-to-end (Phase 2.1: Sequence management #25)
• JSONB editing works with nested objects (Phase 2.2: JSONB inline editing #26)
• At least one extension type (PostGIS or pgvector) handled (Phase 2.3: Extension-aware type system #27)

At minimum, #25 + #26 + #27 must land before calling Phase 2 core done.

Ship points

Each feature ships independently as a stable update as it lands, closing its own issue — no need to wait for the full Phase 2 set. CP-5 is reached once the minimum bar (#25 + #26 + #27) is met.