PostgreSQL 18 on SQLite

Standing in for a PostgreSQL server means implementing far more than SQL: the frontend/backend wire protocol with its startup packets, authentication handshakes, prepared statements and portals; the system catalogs that clients introspect; and the cluster lifecycle utilities (initdb, pg_ctl) that tools use to create and manage database instances. Real clients probe all of these surfaces, and PostgreSQL's own regression suite pins the expected behaviour down to exact query output.

This task asks for that entire server-side surface from scratch in Zig, with SQLite as the only storage engine underneath: a frontier-difficulty exercise in protocol implementation, SQL semantics translation, and systems engineering, developed fully offline against the bundled PostgreSQL documentation.

Implement a PostgreSQL 18 wire-compatible server in Zig in the project at /app/postgres-sqlite: a single multi-call executable that stands in for PostgreSQL 18.3's server-side entrypoints well enough that PostgreSQL 18 clients and tools cannot tell it apart from a real server.

• The binary dispatches on argv[0] and is invoked as postgres, initdb, and pg_ctl.
• All program logic lives in .zig sources reached from src/main.zig, built with bash ./build.sh; SQLite is the storage engine (linked via -lsqlite3).
• Behaviour is exercised by PostgreSQL's own regression tests: /app/run-tests.sh runs everything, or named tests such as run-tests.sh boolean int4.
• build.sh compiles only .zig sources, so any data the program needs must live inside them as Zig literals rather than in separate files.

A Zig scaffold at /app/postgres-sqlite with a fixed build.sh, a visible slice of PostgreSQL's core regression suite at /app/tests as the behavioural spec with the /app/run-tests.sh runner, the complete offline PostgreSQL 18 documentation at /reference/postgresql-docs/ (readable with w3m), and the packaged psql client and admin tools for local testing. Zig 0.15.2 and SQLite are preinstalled; the machine is offline and a sandbox-timer CLI reports the remaining budget. The real PostgreSQL 18.3 server binaries exist in the image but are locked root-only; the agent cannot run or read them.

A clean-room verifier, separate from the agent's environment, reconstructs the scored project from the pristine build.sh plus only the agent's .zig sources, then runs PostgreSQL's core regression schedule through pg_regress against the candidate server. It uses a three-uid choreography: the orchestrator runs as root, the candidate server builds and runs as the non-root agent user, and pg_regress and psql run as a third uid, so candidate code can neither kill the test driver nor tamper with its results. The trusted per-test signal is pg_regress's exit code, captured by root into a nonce-named root-only directory.

• The scored suite is a semantic-preserving mutation of the public one: identifiers are consistently renamed (extracted with the PostgreSQL parser at image build) and expected outputs regenerated by the real server, so hardcoding upstream outputs fails while a general implementation passes.
• The reward is the fraction of scored tests passed, against a fixed denominator of what real PostgreSQL 18.3 passes under the same harness (measured at image build, so the ceiling is exactly 1.0). Skipped or timed-out tests count as failures, and a no-op stub scores approximately 0.
• Binary-provenance checks zero the result: a candidate that is byte-identical to a real server binary, links PostgreSQL libraries, is a C-built ELF with no Zig provenance, or has a real server binary vendored anywhere in the workspace fails hard, as do build failures and reset violations.