feat: add older versions of the wrappers extension

[yvan-sraka]

This PR add a few commits on top of #1743

Summary by CodeRabbit

• Chores
  • Appended a suffix to select PostgreSQL version strings and expanded the wrappers registry with many new releases and metadata.
  • Broad dependency and packaging updates across multiple wrapper releases, regenerating lockfiles and refreshing supported toolchains and PG targets.
• New Features
  • Added a CLI helper to discover and maintain extension-version mappings automatically.
• Documentation
  • Added guidance for automating version updates with example usage and verification steps.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@nix/ext/scripts/update_versions_json.py`:
- Around line 46-49: The for-loop over tags uses an unused variable commit_hash;
change the loop to for tag, _ in tags.items(): (or for tag in tags:) so the
intent is clear and the unused variable is removed—update the loop that
references tags and peeled_tags (the block starting with "for tag, commit_hash
in tags.items():") to use an underscore or iterate only over tag when checking
and assigning peeled_tags[tag].

🧹 Nitpick comments (1)

nix/ext/scripts/update_versions_json.py (1)

17-19: Consider adding a timeout to prevent indefinite hangs.

Network operations like git ls-remote and nix-prefetch-git could hang indefinitely on network issues. Adding a timeout improves robustness for this maintenance tool.

♻️ Proposed fix

-def run(cmd: List[str]) -> str:
-    result = subprocess.run(cmd, capture_output=True, text=True, check=True)
+def run(cmd: List[str], timeout: int = 300) -> str:
+    result = subprocess.run(cmd, capture_output=True, text=True, check=True, timeout=timeout)
     return result.stdout.strip()

[coderabbitai]

Actionable comments posted: 4

🤖 Fix all issues with AI agents

In `@nix/ext/scripts/update_versions_json.py`:
- Around line 13-14: The VERSIONS_JSON_PATH currently points to "versions.json"
which is relative to the current working directory; update it to be anchored to
the script file so it always targets the nix/ext/versions.json file. In
update_versions_json.py, import Path from pathlib and change VERSIONS_JSON_PATH
to compute Path(__file__).resolve().parent / "versions.json" (keep
POSTGRES_VERSIONS unchanged) and use that Path for open/read/write operations so
the script writes to the script directory regardless of CWD.

In `@nix/ext/wrappers/default.nix`:
- Around line 64-66: Align the existence check used by cargoLock.lockFile with
postPatch by testing the file path instead of the directory: update the
conditional in cargoLock.lockFile to use builtins.pathExists
./v${version}/Cargo.lock (the full file path) and fall back to
"${src}/Cargo.lock" when that file is absent; this mirrors the check in
postPatch and ensures the exact Cargo.lock file is validated.
- Line 95: The version comparison for pgrxBinaryName is inverted: change the
builtins.compareVersions call so pgrxVersion is the first argument and "0.7.4"
is the second (i.e., use builtins.compareVersions pgrxVersion "0.7.4" >= 0) so
that pgrxBinaryName resolves to "pgx" for pgrx versions >= 0.7.4; update the
expression referencing pgrxBinaryName accordingly.

In `@nix/ext/wrappers/v0.1.4/0002-bump-pgrx-to-0.6.1.patch`:
- Around line 535-547: The log level was unintentionally raised by replacing
elog(PgLogLevel::DEBUG1, ...) with log!(...), which emits at PostgreSQL's LOG
level; in the log_debug function (and any similar uses) restore the original
DEBUG1 verbosity by replacing the log! call with the pgx debug1! macro (i.e.,
use debug1!("wrappers: {}", msg)); ensure you update only the call in log_debug
(and any other places where elog(..., DEBUG1) was replaced) to use debug1! to
preserve the original DEBUG1 behavior.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Fix versions.json path resolution (currently relative to CWD).
Running the script from repo root (as documented) will write to ./versions.json, not nix/ext/versions.json. Anchor the path to the script location to avoid updating the wrong file.

🔧 Proposed fix

-VERSIONS_JSON_PATH = "versions.json"
+VERSIONS_JSON_PATH = Path(__file__).resolve().parents[1] / "versions.json"
@@
-    if not Path(VERSIONS_JSON_PATH).exists():
+    if not VERSIONS_JSON_PATH.exists():
         return {}

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	POSTGRES_VERSIONS: List[str] = ["15", "17"]
	VERSIONS_JSON_PATH = "versions.json"
	POSTGRES_VERSIONS: List[str] = ["15", "17"]
	VERSIONS_JSON_PATH = Path(__file__).resolve().parents[1] / "versions.json"

🤖 Prompt for AI Agents

In `@nix/ext/scripts/update_versions_json.py` around lines 13 - 14, The
VERSIONS_JSON_PATH currently points to "versions.json" which is relative to the
current working directory; update it to be anchored to the script file so it
always targets the nix/ext/versions.json file. In update_versions_json.py,
import Path from pathlib and change VERSIONS_JSON_PATH to compute
Path(__file__).resolve().parent / "versions.json" (keep POSTGRES_VERSIONS
unchanged) and use that Path for open/read/write operations so the script writes
to the script directory regardless of CWD.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n nix/ext/wrappers/default.nix | sed -n '85,105p'

Repository: supabase/postgres

Length of output: 1116

---

🏁 Script executed:

cat > /tmp/test_versions.nix << 'EOF'
# Testing builtins.compareVersions behavior
# compareVersions a b returns:
# -1 if a < b
#  0 if a == b
#  1 if a > b

let
  v1 = "0.7.3";
  v2 = "0.7.4";
  v3 = "0.7.5";
in
{
  # Test: compareVersions "0.7.4" "0.7.3" should return 1 (0.7.4 > 0.7.3)
  test1 = builtins.compareVersions "0.7.4" "0.7.3";
  # Test: compareVersions "0.7.4" "0.7.5" should return -1 (0.7.4 < 0.7.5)
  test2 = builtins.compareVersions "0.7.4" "0.7.5";
  # Test: compareVersions "0.7.3" "0.7.4" should return -1 (0.7.3 < 0.7.4)
  test3 = builtins.compareVersions "0.7.3" "0.7.4";
}
EOF

Repository: supabase/postgres

Length of output: 43

---

🏁 Script executed:

rg "compareVersions" -A 2 -B 2

Repository: supabase/postgres

Length of output: 5810

---

🏁 Script executed:

cat -n nix/ext/wrappers/default.nix | sed -n '85,110p'

Repository: supabase/postgres

Length of output: 1333

---

Fix argument order in compareVersions for pgrxBinaryName.
The current expression builtins.compareVersions "0.7.4" pgrxVersion >= 0 inverts the logic—it selects "pgx" for versions ≤0.7.4 instead of ≥0.7.4.

🔧 Proposed fix

-pgrxBinaryName = if builtins.compareVersions "0.7.4" pgrxVersion >= 0 then "pgx" else "pgrx";
+pgrxBinaryName = if builtins.compareVersions pgrxVersion "0.7.4" >= 0 then "pgx" else "pgrx";

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	pgrxBinaryName = if builtins.compareVersions "0.7.4" pgrxVersion >= 0 then "pgx" else "pgrx";
	pgrxBinaryName = if builtins.compareVersions pgrxVersion "0.7.4" >= 0 then "pgx" else "pgrx";

🤖 Prompt for AI Agents

In `@nix/ext/wrappers/default.nix` at line 95, The version comparison for
pgrxBinaryName is inverted: change the builtins.compareVersions call so
pgrxVersion is the first argument and "0.7.4" is the second (i.e., use
builtins.compareVersions pgrxVersion "0.7.4" >= 0) so that pgrxBinaryName
resolves to "pgx" for pgrx versions >= 0.7.4; update the expression referencing
pgrxBinaryName accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

pgrx 0.6.x logging macros log! debug1 PgLogLevel

💡 Result:

In pgrx 0.6.x, the common pattern is:

1) Use the level-specific macros (no PgLogLevel needed)

These are exported via pgrx::prelude::* (and also exist under pgrx::pg_sys). They take format!-style arguments:

use pgrx::prelude::*;

log!("Hello from LOG");        // LOG level
debug1!("Hello from DEBUG1");  // DEBUG1 level

log! logs at PostgreSQL LOG level, and debug1! logs at PostgreSQL DEBUG1 level. [1][2][3]

2) Use ereport! when you need an explicit PgLogLevel (and usually an SQL error code)

PgLogLevel is the enum of Postgres log levels (e.g., DEBUG1, LOG, WARNING, ERROR, etc.). [4]

use pgrx::prelude::*;
use pgrx::pg_sys::elog::PgLogLevel;
use pgrx::PgSqlErrorCode;

ereport!(
    PgLogLevel::DEBUG1,
    PgSqlErrorCode::ERRCODE_SUCCESSFUL_COMPLETION,
    "message with explicit PgLogLevel"
);

ereport! is also what you use when you must attach a specific SQLSTATE / PgSqlErrorCode. [5][4]

3) Seeing messages depends on PostgreSQL log settings

Whether DEBUG1/LOG output appears is controlled by PostgreSQL configuration (e.g., log_min_messages, client_min_messages). The macros emit at those levels; Postgres decides whether to display/store them. [2][1]

Sources:
[1] https://docs.rs/pgrx/latest/i686-pc-windows-msvc/pgrx/macro.log.html
[2] https://docs.rs/pgrx/latest/i686-pc-windows-msvc/pgrx/macro.debug1.html
[3] https://docs.rs/pgrx/latest/pgrx/prelude/index.html
[4] https://docs.rs/pgrx/latest/pgrx/pg_sys/submodules/elog/enum.PgLogLevel.html
[5] https://docs.rs/pgrx/latest/pgrx/prelude/macro.ereport.html

---

🌐 Web query:

pgx crate 0.6 documentation logging elog debug level

💡 Result:

In pgx 0.6.x, Postgres “elog-style” logging is done via pgx’s logging macros (re-exported in pgx::prelude::*), e.g. debug1! … debug5!, plus log!, info!, notice!, warning!, error!, and the lower-level ereport! macro. [1]

Example (DEBUG level):

use pgx::prelude::*;

#[pg_extern]
fn demo() {
    debug1!("hello from pgx debug1");
    debug3!("more detail at debug3");
}

If your DEBUG* messages aren’t showing up, you must configure PostgreSQL to emit them:

• Server log: set log_min_messages to DEBUG1 (or DEBUG2/…/DEBUG5) or lower. [2]
• Client (psql) output: set client_min_messages to DEBUG1 (or lower). [3]

For example:

SET client_min_messages = DEBUG1;
-- and/or
SET log_min_messages = DEBUG1;

Sources: [1] https://docs.rs/pgx/latest/pgx/ , [2] https://postgrespro.com/docs/postgresql/current/runtime-config-logging , [3] https://www.postgresql.org/docs/9.1/runtime-config-logging.html

---

Change in logging level from DEBUG1 to LOG. The code changed from elog(PgLogLevel::DEBUG1, ...) (DEBUG level) to log!(...) (LOG level). In pgx 0.6.x, log! emits at PostgreSQL's LOG level, which is higher in verbosity than DEBUG1. To maintain DEBUG1 level, use debug1!("wrappers: {}", msg); instead.

🤖 Prompt for AI Agents

In `@nix/ext/wrappers/v0.1.4/0002-bump-pgrx-to-0.6.1.patch` around lines 535 -
547, The log level was unintentionally raised by replacing
elog(PgLogLevel::DEBUG1, ...) with log!(...), which emits at PostgreSQL's LOG
level; in the log_debug function (and any similar uses) restore the original
DEBUG1 verbosity by replacing the log! call with the pgx debug1! macro (i.e.,
use debug1!("wrappers: {}", msg)); ensure you update only the call in log_debug
(and any other places where elog(..., DEBUG1) was replaced) to use debug1! to
preserve the original DEBUG1 behavior.