Chapter 27: platforms, one build graph for every Postgres major

An extension is compiled against one Postgres major's headers, and a library built for 18 will not load into 17. The usual answer is to build twice, with a setting flipped in between. buck has a better one: make the major part of the configuration, so one graph holds every major at once, and buck2 test //... builds and tests them all in a single run.

This folder defines that configuration. A constraint named pg_major has one value per supported major, and a platform pgNN is the host's own platform plus that value. Anything that differs by major branches on it with pg_major_select (from build/defs.bzl): pgrx's pgNN feature, bindgen's pg_config, the server a test starts.

flowchart TD
  D["build/defs.bzl: PG_MAJORS = 17, 18"] --> C["constraint pg_major: pg_major_17, pg_major_18"]
  C --> P17["platform pg17"]
  C --> P18["platform pg18"]
  P17 --> T17["tests:happy_path-pg17"]
  P18 -. "the default, newest" .-> T18["tests:happy_path"]
  P17 --> N["nix/package.nix: --target-platforms //platforms:pg17"]

Every test gets a twin per older major (first_party_test emits <name>-pg17 with that platform as its default), and the nix package builds one major at a time with --target-platforms //platforms:pgNN. Anything built without the constraint gets the newest.

The other half of this folder is the execution platform: where buck runs its actions. It is the prelude's own default (local, on the host's CPU and OS) with one addition, an opt-in remote cache, off unless the machine's own buck configuration turns it on. Anywhere else, it is exactly the default, and the repository never needs the cache or its credentials to build.

Try it. nix develop -c buck2 build //crates/postjevsql:ext --target-platforms //platforms:pg17 builds the extension for 17.

For the people who maintain it

FileWhat
BUCKThe pg_major constraint, its values and the pgNN platforms from PG_MAJORS, and :execution, the platform .buckconfig names.
execution.bzlcached_execution_platform: the prelude default with remote_cache exposed, read from [buildbuddy] cache. Actions always run locally; the cache is checked first and local results uploaded.

← Previous: Chapter 26, toolchains/ · Up: postjevsql · Next: Chapter 28, third-party/ →