← ClaudeAtlas

pg-extension-lablisted

Develop, test, benchmark, and operate PostgreSQL extensions with reusable harnesses and reference protocols. Use for C/PGXS or Rust/pgrx extension work, planner hooks, CustomScan or index AM design, pg_regress/pg_isolation_regress TDD, filtered ANN/vector benchmarks, matched-recall and pages-per-query analysis, bounded parameter-space exploration, Pareto curves, hypothesis/evidence/report management, accelerator-vs-CPU crossover, resource Pareto tuning, Shape B microservice extensions, Shape C sidecar daemons, service-boundary contracts, async outbox workers, and SECURITY hardening. Balances docs, code evidence, and execution results. Includes copy-ready test, benchmark, contract, and ops assets. Not for projects without a PostgreSQL extension layer.
ysys143/pg-extension-lab · ★ 1 · AI & Automation · score 74
Install: claude install-skill ysys143/pg-extension-lab
# pg-extension-lab — a harness to build, test, scenario, benchmark, and tune a PostgreSQL extension **pg-extension-lab is a harness for validating a PostgreSQL extension's observable behavior in an isolated, reproducible environment, separately from its implementation** — covering **three architecture shapes** and **five reference categories**. Use it not only to build an extension from scratch but to design tuning experiments, write scenarios, and run isolation/regression tests against an existing one. Start with the mental model, identify your shape, then open the category that matches the request — each category has a `README.md` index that links to dense, single-topic detail files (progressive disclosure: this file → category README → detail file). Core mindset: **[`references/mental-models.md`](references/mental-models.md)**. ## Architecture shapes this covers ``` Shape A — pure C / PGXS or Rust/pgrx extension (e.g. a custom index access method) SQL caller → access method / planner hook / pg_extern function → on-disk index pages Shape B — DB extension + external microservice (the service OWNS data) sync: PostgreSQL (SQL function) → HTTP → service (FastAPI/gRPC) → SQL → database async: SQL function → outbox row + NOTIFY → LISTEN worker → service → UPDATE result table Shape C — DB extension + co-located compute sidecar (the daemon owns a costly RESOURCE, not data) N backends → Unix socket/shm → one long-lived daemon holding a device context / model / pool