Sort column definitions stably in order_column_definitions - #66
Open
lucasmazza wants to merge 1 commit into
Open
Sort column definitions stably in order_column_definitions#66lucasmazza wants to merge 1 commit into
order_column_definitions#66lucasmazza wants to merge 1 commit into
Conversation
Owner
|
Huh, good catch on that stray gitlink - my bad! Can you split this into a separate PR? |
Contributor
Author
Running `db:migrate` on macOS reordered CHECK constraint lines in db/structure.sql, while the same migration in Docker left the file untouched. Same gem version, same Ruby, same database — only the platform differed. `order_column_definitions` keys each line inside a CREATE TABLE body on its first word. Column lines key on the column name, so they get unique keys. Every inline CHECK constraint keys on the literal word "CONSTRAINT", so they all tie. `sort_by!` is not stable and delegates to the platform's qsort: glibc happens to preserve the input order of tied lines, BSD shuffles them. Breaking ties by the original index keeps pg_dump's own ordering, which is what the Linux output already produced. Feeding a real 1558-constraint structure.sql back through the sort now returns it byte for byte, so existing schema files see no churn. One caveat on the regression test: it fails on macOS without the fix, but passes either way on glibc, where the unstable sort happens to do the right thing. CI runs on ubuntu, so it guards the behavior rather than reproducing the failure there.
lucasmazza
force-pushed
the
lm/fix-unstable-column-definition-sort
branch
from
August 13, 2026 21:29
148fcc6 to
a4d370a
Compare
Contributor
Author
|
@lfittl this PR now has only the original sorting fix and should be ready for merge :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With
order_column_definitionsenabled, the same schema dump produces differentstructure.sqloutput depending on the platform. Runningdb:migrateon macOS reorders inline CHECK constraint lines; running it on Linux against the same database leaves them alone. The result is a schema file that churns whenever contributors migrate on different operating systems.order_column_definitionskeys each line inside aCREATE TABLEbody on its first word. Column lines key on the column name, so their keys are unique, but every inline CHECK constraint keys on the literal wordCONSTRAINTand they all tie.sort_by!isn't stable and delegates to the platform's qsort — glibc happens to preserve the input order of tied lines, BSD doesn't.Breaking ties by the original index keeps pg_dump's own ordering (alphabetical by constraint name), which matches what the Linux output already produced, so existing schema files sort to exactly what they already contain.
One note on the regression test: it fails on macOS without the fix, but passes either way on glibc, where the unstable sort happens to land on the right answer. CI runs on ubuntu, so it guards the behavior rather than reproducing the failure there.
Rebased on top of #67, so this is now a single commit touching
clean_dump.rband its test.