Repository navigation
fix: keep the plain xpg name for multi-version builds - #18
Conversation
The binary split named every build after its default version, so the all-versions build became xpg17 and consumers calling xpg broke. Only a build pinned to a single version takes the version suffix; a build that selects the version with -v keeps the name xpg. The default flake app now points at the all-versions build.
|
Agree this was a miss on my part. Looks good, just going to run locally and will approve after. FWIW I think that I would like us to move away from packaging all postgres versions in a single binary altogether though. Ideally the xpg17 target should allow the use of Also I do wonder if we should be using the minor version as well (xpg17.2 for example). |
|
@steve-chavez I dont have merge rights on this repo. Can you please help in merging this Pr please? |
Also we probably want to cut a release after. |
|
@utkarash2991 Done, please mention it internally. Idk what's up with the permissions. |
After the binary split the all-versions build is named
xpg17, so anything callingxpgfrom awithExtensionsshell gets command not found. The README still showsxpg -h, so I assume the plain name was meant to stay for that build.This names a build
xpgNNonly when it is pinned to a single version, as theforVersionspackages are, and keepsxpgwhen the version is selected with-v. The default flake app now points at the all-versions build, sincexpg17has nobin/xpg. The tests job follows the rename.Needed for supabase/supautils#260, which bumps xpg past the split.