Open Data, Traceable History

Getting the structured data

Everything this site does interactively comes from local JSON. You can download the full dataset and analyse it yourself, generate migration checks, or build other tools on top of it.

versions in the JSON is ordered oldest first. Each relations entry carries the catalog name, its kind, its coverage boundaries, per-version column definitions, and the adjacent-version change records.

{
  "name": "pg_class",
  "kind": "catalog",
  "first_version": "9.0",
  "last_version": "19",
  "versions": {
    "18": {
      "description": "...",
      "source_url": "https://www.postgresql.org/docs/18/catalog-pg-class.html",
      "columns": [{"name": "relname", "type": "name", "description": "..."}]
    }
  },
  "changes": []
}

Every version also has its own JSON and CSV — for example PostgreSQL 9.0 JSON, 9.0 CSV, 18 JSON, 18 CSV, and 19 preview JSON. Each relation has its own file too, such as pg_class.json.

Coverage

17 PostgreSQL major versions: 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, and 10 through 19. Of these, 18 is the current stable major and 19 is pinned to the beta 3 preview snapshot. Older versions use their corresponding historical manuals and fixed source material.

Relations are grouped into system catalogs, system views, statistics views, and progress reports. Cross-checking a complete release source inventory against fresh instances of 17 exact versions covers every core pg_catalog ordinary table and view. Detailed counts and per-item corrections are in Coverage and Calibration.

What is recorded here is structural change between the selected major-version snapshots. It is not a complete event log of every patch release and every source commit, and it does not cover system tables created by extensions.

Historical formats and supplementary fields

In early system catalogs the OID column was sometimes an implicit system column: present in the source, but not expanded by SELECT *. This site keeps those columns and marks them “implicit” rather than mixing them in with explicit ones. Grouped notations such as stakindN in the official manual also have to be expanded to real columns against the source; the original documentary grouping and supplementary notes are kept alongside the column.

The 9.0 and 9.1 statistics-view documentation gives only an overview in places, so column structure follows the SQL definition of that version. Where a later document is needed for an explanation, description_source records where the wording came from; this does not change which version the column structure belongs to. Detail pages link to the official manual and, where available, the source definition.

How a change is decided

• Catalog added or removed: the relation’s presence differs between two adjacent versions.
• Column added or removed: column sets are aligned by name and compared at both ends.
• Type change: a column of the same name has a different normalised type.
• Attribute and order change: transitions between implicit and ordinary columns, nullability, type modifiers, array dimensions, and the relative order of shared columns.
• Description update: the wording of a column or catalog description changed; recorded separately and not counted as a structural change by default.
• Column rename: presented as an old column removed and a new column added. Renames are never guessed.

The home-page matrix shows green for present and gold for added or structurally changed in an adjacent version. The column matrix on a relation’s detail page additionally shows removals. Hovering a matrix cell shows the type for that version; clicking opens that version’s column descriptions.

9.0 is the coverage baseline. “First seen in 9.0” means the relation already existed in this project’s earliest snapshot — not that it was introduced in PostgreSQL 9.0. Version 19 is pinned to the REL_19_BETA3 preview snapshot and must not be read as released, stable structure.

Sources, archives, and reproduction

The complete source code, original JSON, deployment assets, and 155 page routes of the upstream PG Catalog Almanac are preserved under sources/almanac/. Its site/offline.html is a self-contained offline entry point to the original site; the original HTML, JavaScript, and CSS are kept verbatim alongside it.

The extended data is extracted from the official PostgreSQL release documentation and the matching source code, with the original material preserved under sources/postgresql/. The parsed JSON produces the data mirror Hugo needs plus a static page per relation, which the Oink 1.0.0 theme then builds. Download manifests and checksums are kept so provenance can be traced and the build reproduced offline.

The original material is under its respective PostgreSQL or MIT license, with copyright and license text kept next to the source files. For where this project came from and who it credits, see About.

Runtime calibration

Every column structure was checked item by item against a fresh instance of the corresponding release. This fixed userepl, missing from the 9.1 user view; the documented name of pg_policies.permissive in 10 through 12; and wrong types recorded for older pg_stats_ext, the replication views, and others. The documented wording is preserved in documented_type / documented_name, and documented_references is kept when a reference is corrected.

Column records also carry attnum, type_oid, not_null, type_modifier, and array_dimensions. Each catalog’s system_columns holds the six common system attributes separately, keeping the full measured result without mixing them into the ordinary column matrix. Every snapshot’s runtime_validation gives the exact minor version, the source tag, and the SHA-256 of the raw measurement file.