Skip to content

Add research report on psql plugin system feasibility#17

Open
NikolayS wants to merge 4 commits intomasterfrom
claude/psql-plugin-research-Akvaz
Open

Add research report on psql plugin system feasibility#17
NikolayS wants to merge 4 commits intomasterfrom
claude/psql-plugin-research-Akvaz

Conversation

@NikolayS
Copy link
Owner

Summary

This adds a comprehensive research document analyzing why PostgreSQL's psql client lacks a plugin/extension system despite the server having 26+ hook points, and what would be required to implement one.

Key Changes

  • New file: research/psql-plugin-system-research.md (362 lines)
    • Executive summary of the problem and findings
    • Detailed architectural analysis of barriers in the psql codebase (monolithic command dispatch, main loop, query execution, tab completion, global state, lack of dynamic loading)
    • Comparison with PostgreSQL server's rich hook ecosystem
    • Comprehensive review of previous discussions on pgsql-hackers (finding that no formal plugin system proposal has ever been submitted)
    • Historical case studies of how difficult it is to add even simple features to psql (\if, \crosstabview, \watch)
    • Analysis of cultural and community factors preventing such a proposal
    • Catalog of tools that exist because psql cannot be extended (pgcli, pgAdmin, DBeaver, rpg, pspg, usql)
    • Specification of what a minimum viable plugin API would require
    • Effort estimation (2,700 LOC, 15-20 review cycles, 2-4 release cycles)
    • Strategic assessment of why this hasn't been proposed and what would be needed for success
    • Extensive references to mailing list threads, blog posts, wiki pages, and source code locations

Notable Details

  • Identifies the core architectural problem: exec_command() in command.c uses a 50+ branch if/else chain with no command registry or hook points
  • Documents that the main loop (662 lines) and query execution (200+ lines) have zero extensibility hooks
  • Notes that tab-complete.in.c (7,227 lines) is the largest single file in psql with no provider interface
  • Highlights that variable hooks exist internally but were never exposed as a public API
  • Contrasts with MySQL's formal client plugin architecture
  • Provides concrete effort estimates and identifies the minimum viable scope for upstream acceptance

https://claude.ai/code/session_013B3EQeajCeqgoTKWLVMZkK

claude added 4 commits March 14, 2026 15:35
…d historical analysis

Comprehensive research into why PostgreSQL's psql client remains monolithic
after 25+ years, covering:
- Codebase analysis: hardcoded command dispatch (50+ if/else branches),
  zero hook points in main loop/query execution, no dynamic loading
- Server contrast: 26+ hooks vs zero client hooks
- pgsql-hackers history: no formal plugin proposal ever submitted
- Case studies: \if took 17 files/2172 insertions; \crosstabview needed
  two commitfest cycles
- Cultural factors: conservative process, "not the project" mindset
- Strategic assessment for proposing upstream

https://claude.ai/code/session_013B3EQeajCeqgoTKWLVMZkK
Added findings from deep mailing list search:
- 2012 "Plugin For Console" thread (pgAdmin embedding, not psql extensibility)
- 2017 psql variable hooks thread (internal only, Tom Lane/Verite/Frost)
- Pipeline mode timeline: 4 years from libpq API to psql commands
- \watch evolution across 5 major releases over 12 years
- .psqlrc as the sole customization surface (2008 Momjian thread)
- Key community members for psql patches (Lane, Coelho, Huinker, Verite, Stehule)
- FOSDEM '21 talk on server extensibility resistance

https://claude.ai/code/session_013B3EQeajCeqgoTKWLVMZkK
…alks

Key additions from final research pass:
- 2008 libpq Object Hooks (Merlin Moncure/Tom Lane): closest thing to a
  client-side extensibility proposal in PostgreSQL history. Lane called
  the hook-name approach "broken-by-design"
- 2008 libpq pqtypes Hook API (Andrew Chernow): also not adopted
- 2026 per-connection auth hooks (Karlsson/Champion): most recent
  client-side hook work, narrow scope
- pspg as the de facto "plugin pattern" via PSQL_PAGER env var
- MySQL client plugin system comparison (dlopen-based, PostgreSQL has
  no equivalent)
- PGConf EU talks: Huinker 2017 "Getting By With Just psql",
  Frost 2018 "Hacking PostgreSQL"

https://claude.ai/code/session_013B3EQeajCeqgoTKWLVMZkK
After 12+ targeted web searches: no formal RFC/patch/commitfest entry
found, but the picture is more nuanced:
- 2008 libpq hooks (Moncure) were the closest client-side proposal
- Self-censorship is the likely explanation, not lack of interest
- Community quotes: "getting stuff into forks/plugins is orders of
  magnitude easier than the kernel itself"
- pgPedia documents a \set-based backslash alias workaround
- Huinker's PGConf EU 2017 talk pushed psql's limits but stopped
  short of proposing a plugin system

https://claude.ai/code/session_013B3EQeajCeqgoTKWLVMZkK
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants