You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Document (or provide) an ordering guarantee for test/install/*.sql files #111
base.mk's test/install schedule generation (~line 298) iterates $(TEST_INSTALL_SQL_FILES) (a $(wildcard test/install/*.sql) expansion) with no explicit sort, so the order install files run in depends entirely on whatever order Make's wildcard happens to return (in practice, alphabetical on most platforms/filesystems, but this isn't a documented guarantee anyone should rely on).
This bit a real consumer: two install files had an implicit dependency (one provisions roles the other's CREATE EXTENSION ... CASCADE requires to already exist), named such that alphabetical order ran them backwards. It "worked" for a long time anyway, purely by accident — an unrelated step elsewhere in the same test run happened to provision the same roles as a side effect, masking the real ordering bug until that masking step was removed. Confirmed by regenerating the schedule and observing the actual (wrong) order, then by explicitly dropping the roles and watching a real test run fail without the masking step.
Neither pgxntool/CLAUDE.md nor any other doc says anything about whether file order is guaranteed or how to control it if a consumer has an inter-file dependency like this. Two possible directions, either would resolve this:
Document that ordering is NOT guaranteed and consumers with dependencies between install files must encode that in the filenames themselves (e.g. a numeric prefix) to get deterministic alphabetical ordering.
Provide an actual ordering mechanism (e.g. read files from a schedule file each consumer maintains, rather than a bare wildcard), and document it.
Filing as a documentation gap at minimum — happy to help with a PR for whichever direction is preferred.
One more thing worth flagging, since it affects which of the two directions above is actually viable: pgxntool/CLAUDE.md and .claude/ are excluded from the subtree distribution via .gitattributes export-ignore — they're dev-facing docs for people working on pgxntool itself, not something that lands in a consuming extension's checkout at all. So documenting this in a pgxntool-internal CLAUDE.md (including a hypothetical one under test/) wouldn't actually reach anyone consuming pgxntool via git subtree add -- it'd only be visible to people working directly in this repo.
For a consumer to actually see this, it'd need to live in something that is distributed -- README.asc is the obvious candidate (it's real end-user-facing documentation, not export-ignore'd). This probably needs some actual thought about where AI-assistant-facing guidance vs. human-facing documentation should each live for something like this, rather than just picking whichever file happens to be closest to the code.
Activity
jnasbyupgrade commentedon Aug 28, 2026
🤖 (Claude)
One more thing worth flagging, since it affects which of the two directions above is actually viable:
pgxntool/CLAUDE.mdand.claude/are excluded from the subtree distribution via.gitattributes export-ignore— they're dev-facing docs for people working on pgxntool itself, not something that lands in a consuming extension's checkout at all. So documenting this in a pgxntool-internalCLAUDE.md(including a hypothetical one undertest/) wouldn't actually reach anyone consuming pgxntool viagit subtree add-- it'd only be visible to people working directly in this repo.For a consumer to actually see this, it'd need to live in something that is distributed --
README.ascis the obvious candidate (it's real end-user-facing documentation, notexport-ignore'd). This probably needs some actual thought about where AI-assistant-facing guidance vs. human-facing documentation should each live for something like this, rather than just picking whichever file happens to be closest to the code.Merge upstream/master into issue-111-install-order
Fix HISTORY.asc: sort issue numbers in ascending order
Guarantee test/install/*.sql schedule ordering (Postgres-Extensions#120)