Advance the pin to libpg_query 18.0.0 (PostgreSQL 18.4)

.github/workflows/regenerate.yml

@@ -1,7 +1,7 @@
 name: regenerate
 
 # Scheduled proof that the committed goldens are reproducible byte-for-byte
-# from the pinned oracle (libpg_query 17-6.2.2 via pg_query_go v6.2.2, cgo).
+# from the pinned oracle (libpg_query 18.0.0 via pg_query_go's wrapper, cgo).
 # This is the only place cgo ever runs; the main module never links it.
 
 on:
@@ -20,12 +20,17 @@ jobs:
       - uses: actions/setup-go@v5
         with:
           go-version-file: go.mod
-      - name: Fetch pinned corpora
+      - name: Install protoc (for the oracle's pg_query_go build)
+        run: sudo apt-get update && sudo apt-get install -y protobuf-compiler
+      - name: Fetch pinned corpus
         run: |
-          git clone --depth 1 --branch 17-6.2.2 https://github.com/pganalyze/libpg_query /tmp/libpg_query
-          git clone --depth 1 --branch v6.2.2 https://github.com/pganalyze/pg_query_go /tmp/pg_query_go
+          git clone --depth 1 --branch 18.0.0 https://github.com/pganalyze/libpg_query /tmp/libpg_query
+      - name: Build the oracle's pg_query_go dependency
+        # No pg_query_go release ships libpg_query 18 yet; this reproduces
+        # pg_query_go's `make update_source` against the pinned tag.
+        run: ./oracle/update-pg-query-go.sh /tmp/libpg_query
       - name: Regenerate goldens (builds the cgo oracle; several minutes)
         run: |
-          go run ./cmd/regenerate -libpg-query /tmp/libpg_query -pg-query-go /tmp/pg_query_go
+          go run ./cmd/regenerate -libpg-query /tmp/libpg_query -pg-query-go oracle/pg_query_go
       - name: Goldens are reproducible
         run: git diff --exit-code -- parser/testdata

.gitignore

@@ -1,2 +1,4 @@
 # Built cgo oracle binary (go build ./... in oracle/)
 oracle/oracle
+# Oracle dependency populated by oracle/update-pg-query-go.sh
+oracle/pg_query_go/

CLAUDE.md

@@ -1,7 +1,7 @@
 # oliphant development guide
 
 Pure Go port of pg_query_go. Read `PLAN.md` first — it is the contract.
-Pin: libpg_query **17-6.2.2** (PostgreSQL 17.7, patched). No cgo anywhere in
+Pin: libpg_query **18.0.0** (PostgreSQL 18.4, patched). No cgo anywhere in
 the main module; the only module allowed to link pg_query_go (cgo) is
 `oracle/`, and only `cmd/regenerate`/`cmd/difftest` ever run it.
 

PLAN.md

@@ -36,11 +36,13 @@ behind a small hand-written API layer, with **11 patches** applied to upstream
 PostgreSQL before extraction.
 
 Initial pin: **libpg_query `17-6.2.2` (PostgreSQL 17.7)** — the exact tag
-pg_query_go v6.2.2 ships today and the version sqlc builds against
-(`ParseResult.Version == 170007`). libpg_query's main branch is already on
-PostgreSQL 18.4; the plan treats "advance the pin" as a first-class workflow
-(§ Regeneration) rather than targeting a moving version now. When pg_query_go
-cuts a PG 18 major, oliphant re-pins and re-derives its goldens.
+pg_query_go v6.2.2 ships and the version sqlc builds against at the time.
+*(The pin advanced on 2026-08-17: the current pin is **libpg_query `18.0.0`
+(PostgreSQL 18.4)**, `ParseResult.Version == 180004`, via the § Regeneration
+workflow. No pg_query_go release ships libpg_query 18 yet, so the oracle
+builds pg_query_go's wrapper against the 18.0.0 sources locally — see
+`oracle/update-pg-query-go.sh`.)* The plan treats "advance the pin" as a
+first-class workflow (§ Regeneration) rather than targeting a moving version.
 
 Two consequences of the patches matter and are easy to miss:
 

README.md

@@ -10,7 +10,7 @@ error type, same fingerprints. Consumers change one import path:
 +import pg_query "github.com/sqlc-dev/oliphant"
 ```
 
-Pinned to **libpg_query `17-6.2.2`** (PostgreSQL 17.7, patched) — the exact
+Pinned to **libpg_query `18.0.0`** (PostgreSQL 18.4, patched) — the exact
 build pg_query_go v6.2.2 ships. Every golden in `parser/testdata` derives
 from that oracle, byte for byte, and is never edited by hand.