pig build
The pig build command simplifies the full workflow for building PostgreSQL extensions from source. It provides build infrastructure setup, dependency management, and compilation environments for standard and custom PostgreSQL extensions across supported operating systems.
| Command | Description | Notes |
|---|---|---|
build spec | Initialize build specification directory | |
build repo | Initialize required repositories | Requires sudo or root |
build tool | Initialize build tools | Requires sudo or root |
build rust | Install Rust toolchain | Requires sudo or root |
build pgrx | Install and initialize pgrx | Requires sudo or root |
build proxy | Set up Xray clients and servers | Linux: root; macOS client: regular user |
build get | Download source tarballs | |
build dep | Install extension build dependencies | Requires sudo or root |
build ext | Build extension packages | Requires sudo or root |
build pkg | Complete pipeline: get, dep, ext | Requires sudo or root |
Quick Start
The fastest way to set up a build environment and build an extension:
For finer control:
Build Infrastructure
Directory Layout
Build output locations:
- EL systems:
~/ext/pkg/, also accessible through~/rpmbuild/RPMS/ - Debian systems:
~/ext/pkg/, also accessible through~/debbuild/DEBS/
build spec
Set up build specifications and directory layout.
What it does:
- Downloads the RPM or DEB build specification tarball.
- Creates
~/ext/{pkg,src,log,tmp}and the platform build directory. - Links
RPMS/DEBSandSOURCESto~/ext/pkgand~/ext/src. - Syncs makefiles, specs, and Debian packaging files with incremental
rsync.
Working directory: ~/ext/ stores sources, packages, logs, and temporary files. The platform packaging directory is ~/rpmbuild/ or ~/debbuild/.
build repo
Initialize package repositories required for building extensions.
What it does: initializes build repositories with pig repo set -ru: remove old repositories, add required repositories, and refresh package caches. --beta/-b appends the beta module for explicit PostgreSQL 19 beta builds; the stable default path still uses PG14-18.
Options:
-b|--beta: additionally enable PostgreSQL beta repository modules-m|--mirror: select the built-inchinaregion sources
build tool
Install development tools and compilers.
Toolsets:
- Minimal (
mini): GCC/Clang compilers, Make, and generic build essentials; does not install PostgreSQL server/devel packages. - Default /
full: compilers, development libraries, packaging tools such asrpmbuildanddpkg-dev, plus stable PG14-18 build dependencies. --beta: additionally installs PG19 beta server/devel build packages on top of the default toolset.
build rust
Install the Rust toolchain required by Rust-based extensions.
Installed components: Rust compiler (rustc), Cargo, Rust standard library, and development tools. -m|--mirror uses mirror mode and writes rsproxy.cn Cargo configuration.
build pgrx
Install and initialize PGRX, the PostgreSQL extension framework for Rust.
Prerequisites: Rust toolchain and PostgreSQL development headers must be installed first. Default auto-detection only covers stable PG14-18; use -b|--beta, or explicitly pass --pg 19, when PG19 beta is required.
build proxy
Set up Xray clients and servers for build environments with restricted internet access.
The x alias is retained. With no arguments, pig build proxy installs or verifies Xray only.
The client and server role commands are available from PIG v1.9.0.
See the Xray design record for the protocol and migration contract.
Client
One command installs Xray if needed, writes the client configuration, starts its service, and checks
HTTPS through both HTTP and SOCKS. The first listener defaults to 127.0.0.1:12345, with HTTP
and SOCKS sharing that port. An omitted --listen preserves the listener of an existing supported
client. The protocol is VLESS over RAW/TCP, REALITY, and xtls-rprx-vision, with a Chrome fingerprint
and multiplexing disabled.
Choose one connection input: a positional URI, direct connection flags, or --from FILE/-.
client.uri is simply a text file containing one standard vless:// URI, with an optional trailing
newline; its name is arbitrary. --from - reads stdin. Do not mix input forms. --pqv supplies
ML-DSA-65 verification when enabled on the server. Unsupported transports, duplicate URI parameters,
and ambiguous inputs are rejected before setup.
On Linux, run setup as root or with sudo, with systemd running and a repository providing the
Pigsty xray package configured first, for example sudo pig repo add infra -u. Setup uses
/etc/xray.json with mode 0640 and ownership root:xray, the xray service account, and a PIG-owned
systemd drop-in. On macOS, run as your regular user with Homebrew available. Setup uses
~/.config/xray/pig-proxy.json with mode 0600 and its own com.pigsty.xray-proxy LaunchAgent.
For an already configured server, stream the connection directly into client setup. Both ends must use a PIG build containing these commands:
Repeated setup with matching input, ownership, permissions, and service state leaves files and the
running service unchanged. Incorrect managed-file ownership is repaired without changing connection
credentials. A different or unsupported existing client configuration requires --replace --yes; --plan previews the
operation without installation, writes, or service changes. Setup checks both proxy protocols using
https://www.google.com/generate_204 and requires HTTP 204, so the server needs outbound access to
that endpoint. A failed check returns nonzero and restores prior managed files and service state;
an installed package may remain.
The generated shell file defines po, px, and pck. To enable proxy variables in the calling shell:
Server
Server setup supports Linux with the same package, root, and systemd requirements. Require the
advertised public --host and REALITY camouflage --target host:port. The first direct listener
defaults to 0.0.0.0:443; --port changes the advertised public port and first direct listener.
--listen sets an independent bind endpoint. The target must support TLS 1.3 and HTTP/2.
First setup generates a UUID, X25519 key pair, short ID, and ML-DSA-65 seed and verification key.
SNI defaults to the target hostname. Repeating setup retains all authentication fields, SNI, and
protocol settings; an omitted --listen retains the existing listener. Matching configuration, file
ownership and permissions, and service state require no rewrite or restart. With the same --host and --port, export returns the
same canonical URI. Conflicting target/SNI or malformed and ambiguous existing material is rejected
instead of silently rotating credentials. An existing unsupported server configuration is refused.
--export-only requires --export and does not install, modify configuration, start, restart, or
enable the service. It derives client verification material from the existing private material in
process. One supported VLESS/REALITY inbound, account, SNI, and short ID must be unambiguous.
--host and --port describe the external endpoint; a backend port such as 9443 is not inferred as
the public port. Do not combine this read-only mode with setup options.
--export FILE writes mode 0600 and never includes the server private key or seed. Re-exporting
identical content succeeds without rewriting; a different existing file is refused. --export -
explicitly prints one complete credential URI on stdout; diagnostics stay on stderr. Export requires
text output and cannot be combined with JSON/YAML. Ordinary output and plans contain no credentials.
Treat the whole URI and direct authentication flags as credentials; file/stdin input avoids retaining
them as shell arguments.
Server success proves its local listener and service, with public reachability pending a real client
request. PIG does not configure Nginx, firewall rules, or cloud security groups. --proxy-protocol
requires loopback binding and an existing trusted frontend. Port conflicts fail without stopping
another service. Existing V2Ray is not automatically stopped or removed.
Historical VMess form
The historical positional grammar keeps its V2Ray/VMess behavior and first client port 12345:
This Linux compatibility path still needs a repository providing vray, writes /etc/v2ray.json
and /etc/profile.d/proxy.sh, and restarts v2ray. It requires root or sudo; a failed HTTPS check
returns nonzero. The remote user ID is a credential and is redacted from ordinary results.
build get
Download extension source tarballs.
Arguments to pig build get are extension names, package names, or source filenames. Unknown names are treated as source filenames. It does not expand all or std into built-in package sets; list the target package names explicitly for batch downloads.
Some source packages do not map directly to extension names, so pig build get includes special aliases for direct source downloads.
Common special source aliases include: babelfishpg / babelfish, agensgraph / agentsgraph, oriolepg / orioledb, cloudberry, pgedge, pdu, pgdog, rdkit, onesparse, and libfepgutils.
build dep
Install dependencies required to build extensions.
Options:
--pg: specify one or more PostgreSQL major versions. If omitted, pig infers versions from extension metadata or local PostgreSQL installations.
build ext
Compile extensions and create installation packages.
Debug packages are enabled by default. Compiled RPM builds normally add debuginfo and
debugsource packages, while Debhelper-based builds normally add a dbgsym package. Pure SQL,
architecture-independent, or recipe-specific builds may have no debug payload to split. A package
recipe can also make a narrower explicit choice; PIG does not rewrite spec files or debian/rules.
Options:
--pg: specify one or more PostgreSQL major versions.--nodbg: disable automaticdebuginfo/debugsourcepackages on RPM builds anddbgsympackages on DEB builds.
build pkg
Run the complete build pipeline: download, dependency installation, and build.
Options:
--pg: specify one or more PostgreSQL major versions.--nodbg: disable automaticdebuginfo/debugsourcepackages on RPM builds anddbgsympackages on DEB builds.-m|--mirror: prefer thepigsty.ccmirror when downloading source files.
Common Workflows
Workflow 1: Build a Standard Extension
Workflow 2: Build a Rust Extension
Workflow 3: Build Multiple Versions
Troubleshooting
Build Tools Not Found
Missing Dependencies
PostgreSQL Headers Not Found
Rust/PGRX Issues
Extension Build Matrix
Common Extensions to Build
| Extension | Type | Build Time | Complexity | Special Requirements |
|---|---|---|---|---|
| pg_repack | C | Fast | Simple | None |
| pg_partman | SQL/PLPGSQL | Fast | Simple | None |
| citus | C | Medium | Medium | None |
| timescaledb | C | Slow | Complex | CMake |
| postgis | C | Very slow | Complex | GDAL, GEOS, Proj |
| pg_duckdb | C++ | Medium | Medium | C++17 compiler |
| pgroonga | C | Medium | Medium | Groonga libraries |
| pgvector | C | Fast | Simple | None |
| plpython3 | C | Medium | Medium | Python development |
| pgrx extensions | Rust | Slow | Complex | Rust, PGRX |
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)