Pg Feature Plan

Original name

Original description

Drop a heavy, citation-rich implementation plan for a scoped PostgreSQL backend feature — Phase 2 of the two-phase PG planner, the bridge from a brainstorm-with-picked-approach to /pg-implement. Names every src/backend or src/include file that must change with file:line cites at a pinned anchor, enumerates catalog / CATALOG_VERSION_NO / WAL / on-disk / lock-order / extension-ABI risks, proposes the test surface (regress / iso / TAP), structures the patch into independently-reviewable phases, picks a CommitFest landing strategy, and emits the plan-mode plan that /pg-implement executes phase-by-phase with plan-linked commits. **Use proactively whenever the user invokes /pg-plan, says "plan this PG feature", "make a plan for X in PG", "drop a heavy plan", "plan-mode plan for [PG feature]", "i picked option [A/B/C] in the brainstorm, now plan it", "we settled on the [approach] for the [PG topic], write me the phase plan with file:line cites", "spec-to-plan this pgsql-hackers thread", "shadow-implementation plan against [hackers URL]", "REJECT-track plan for CF NNNN", or has a brainstorm doc + a picked approach for a PostgreSQL backend change and wants the file-by-file rollout — even when they don't use the literal word "plan".** Skip when the idea is still exploratory and no approach is picked (use pg-feature-brainstorm first), for product / sprint / Q4 / roadmap / Jira / OKR planning, application architecture planning, Terraform / k8s / Helm / Ansible / CI infrastructure plans, React / Redux / Zustand / Vue / Angular frontend refactor plans, migration plans between non-PG databases (MySQL→PG migration is a DBA migration plan, not a PG feature plan), generic non-PG database feature planning (SQLite, DuckDB, MongoDB, MySQL features), and code-review of an already-submitted patch (use pg-patch-review or review-checklist).