docs: clarify _propagate_part_to_master materialization is delete-order, not just MySQL 1093#1495
Open
dimitri-yatsenko wants to merge 1 commit into
Open
docs: clarify _propagate_part_to_master materialization is delete-order, not just MySQL 1093#1495dimitri-yatsenko wants to merge 1 commit into
dimitri-yatsenko wants to merge 1 commit into
Conversation
…ot just MySQL 1093 Rewrite the docstring to lead with the backend-independent reason: Table.delete deletes in reverse-topological order, so a Part is deleted before its Master; a live master restriction derived from the Part would evaluate empty and the Master would escape deletion. MySQL 1093 is a secondary consequence. Prevents a future MySQL-only 'optimization' that would be a silent integrity bug on PostgreSQL.
MilagrosMarin
approved these changes
Jul 15, 2026
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
2 participants
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.
Follow-up from the 2.3.1
dj.Diagramreview. The_propagate_part_to_masterdocstring justified theto_arrays()master materialization purely as a MySQL-1093 workaround. That framing is incomplete and risks a well-intentioned "PostgreSQL has no 1093, so skip it" change that would be a silent integrity/data-loss bug.The real, backend-independent reason:
Table.deletedeletes per-table in reverse-topological order (table.py:1089), so a Part is deleted before its Master. The Master's restriction is derived from that Part; left as a live subquery it evaluates to empty once the Part is gone, and the Master escapes deletion — reintroducing the compositional-integrity violation the upward walk exists to prevent. Materializing the Master PKs at plan time captures them before any deletion. MySQL 1093 is a secondary consequence.Docstring-only; no behavior change.