Repository navigation
fix: hold back a sequence drop while a held-back table's default still uses it - #166
Merged
Merged
Conversation
…l uses it
A column default names its sequence only inside a string literal
(nextval('public.shared_seq'::regclass)), which the skeleton the check
searches blanks. Without --allow-destructive, a dropped table was held back
but the sequence its default drew on was dropped anyway, failed with
"cannot drop sequence ... because other objects depend on it", and rolled
back the other fixes in its batch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Without
--allow-destructive, a dropped table'sDROPis held back. So is the drop of any type, domain, routine or sequence that the held-back table still uses, which SupaForge finds by searching the table's definition for the name.A column default names its sequence only inside a string literal,
nextval('public.shared_seq'::regclass), and the search ran over a form of the SQL with literals blanked. So the sequence was dropped anyway. That failed withcannot drop sequence shared_seq because other objects depend on it, and rolled back the other fixes in its batch.The search now also covers sequence names in
nextval('…')and'…'::regclassliterals.Found by the corpus case
sequence_shared_and_owned_with_options(after → before), once DBDiff writes that column's change as a plain default change rather than a serial change containing its ownDROP SEQUENCE. The new test fails without the fix; the same scan through the CLI now applies the column change and holds back both drops, with no errors.🤖 Generated with Claude Code