DDX for PostgreSQL — Community

OVERVIEW

Every PostgreSQL contribution we can extract from public sources, attributed to a person, indexed by release. We pull from:

• Git trailers — Reviewed-by:, Tested-by:, Reported-by:, Co-authored-by:, Suggested-by:, Signed-off-by:, plus the commit Author: and Committer: headers. Includes typo'd variants via TRE fuzzy regex (cost ≤ 1 edit).
• Buildfarm — animal-owner attribution from buildfarm.postgresql.org's show_members.pl, scoped to each branch the animal tracks. The owner gets credit per branch as :buildfarm-owner.
• Mailing lists — coming with the next sync. Wiki & Discord — schema reserved; ingest pending.

Identity resolution is conservative — same email = always one person; same name + different email = two clusters flagged needs_review for operator confirmation. 246 of 2,453 clusters currently need review (mostly [email protected] vs [email protected] for the same human).

BY RELEASE

TOP CONTRIBUTORS

METHOD

Per-person pages live at /community/<hash>/ where <hash> is the first 8 hex chars of sha256(canonical_email). Same person renders to the same hash regardless of which alias triggered the link, which keeps URLs stable across re-syncs and avoids leaking email plaintext in the URL bar.

Raw data is in PostgreSQL on fra (community.contributions_raw, community.persons, community.contributions_buildfarm) plus the :person/* and :contribution/* namespaces in the mentat triple store. The 6 community MCP verbs — list_contributors, get_contributor, find_contributions, release_contributors, contribution_summary, discussion_links — query the relational tables directly for speed; the mentat triples are there for cross-namespace joins (e.g. "reviewers of patches authored by X").

If your name is missing or merged with someone else's, please tell us — the community.committer_aliases hard-override table is hand-curated and takes precedence over the auto-clustering pass.

HOW THE BY-RELEASE NUMBERS ARE COMPUTED

The release column an individual contribution falls into is decided by a date heuristic against the commit's committed_at timestamp:

• PG19-dev — commits dated on or after 2025-09-26 (day after PG 18.0 GA)
• PG18 — 2025-07-01 ≤ committed_at < 2025-09-26
• PG17 — 2024-07-01 ≤ committed_at < 2025-07-01
• PG16, PG15, … — same one-year-prior shift, see data.sql
• UCB-historical — committed_at < 1996-01-01 (Berkeley POSTGRES era)

This is approximate, not branch-aware: a backport commit landed on REL_18_STABLE in 2026 will currently be classified as PG19-dev because the classifier looks at committed_at, not the branch the commit lives on. Branch-aware classification is on the roadmap. For each release the columns — people, commits, authored / reviewed / tested / reported / committed / reverted — come from grouping community.contributions_raw by (release, role) and counting distinct commit SHAs per role; revert detection runs against ag_git_commits.message separately.

SCOPE, REVERT DETECTION, DEDUPLICATION

Three deliberate choices behind these numbers:

• Scope: canonical authoritative repos only. Per-release totals and per-person aggregations join community.contributions_raw to ag_repositories on is_authoritative = TRUE: the canonical primary master/main branch of each project we track (postgres-core lives at id = 1; extensions and drivers like pgbouncer, pgpool2, pgdog, postgresql-jdbc, aws-advanced-jdbc-wrapper, psqlodbc each contribute their canonical row). The flattening github mirror (postgres-github, which mirrors every REL_*_STABLE branch into one repo and so multi-counts every commit ~28×), downstream forks (supabase-postgres, postgrespro), and the cfbot CI test repo (postgresql-cfbot, which indexes per-PR branches rather than canonical history) are all excluded. Counting only the canonical master/main branch is the operator-explicit rule: stats reflect contributions to the project, not noise from mirrors and forks of the same commits.
• Reverted column. A commit counts as reverted when its message subject begins with Revert (capital R, space) or its body contains This reverts commit . Both are signals git revert produces; the subject-only path also catches manually-authored revert commits. The reverted column shows distinct revert commits per release.
• Per-role counts use distinct commits. The trailer extractor in community.contributions_raw can fire 2–3 times for a single (commit, person, role) — the explicit Author header insertion plus body Author: trailer plus occasional fuzzy-matches all stand. Aggregations use count(DISTINCT commit_sha) per role to undo this inflation. For example: Tom Lane's PG19-dev authored count went through three shrinkings: ~15,930 raw rows (every trailer fired) → ~5,535 distinct commits across all postgres mirrors after dedup → a few hundred distinct commits on canonical master only after the is_authoritative filter.

VERIFY IT YOURSELF

The full underlying dataset and the aggregation algorithm are published as a self-contained PostgreSQL script: /community/data.sql. The script ships a fresh copy on each refresh and contains:

• CREATE TABLE statements for the schema
• INSERT INTO for every row of community.contributions_raw, community.contributions_buildfarm, community.persons, and the alias tables
• the release-classifier function community.release_for(committed_at)
• SQL views that produce the per-release aggregates the page displays (v_release_totals, v_release_role_breakdown)

Load it into any PostgreSQL 14+ database with psql -f data.sql and run the same queries the page uses. If the numbers don't match, that's a bug; please tell us.

FEEDBACK WELCOME

This page is a community resource and we want to credit everyone correctly. If an alias is missing, two identities should be merged, a release column looks wrong, or you spot a contribution we missed, please tell us. Adjustments to better reflect community participation are the goal — the more accurate the data, the more useful the page.