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
Commit 6501126
Browse filesBrowse the repository at this point in the historyBrowse files
fix(parser/tidb): resolve unqualified SET columns against target's actual columns
Per Codex P1 follow-on catch on PR #20345 — gap in the Bug 6 fix
(commit c4042da). updateMutatesTable's unqualified-column branch
returned true for any unqualified SET when the target was in scope,
regardless of whether the column actually existed on the target.
For
UPDATE test JOIN t1 ON test.c = t1.c SET name = 1 WHERE test.c = 1;
(`name` exists on the joined table but not on `test`),
updateMutatesTable misclassified the UPDATE as mutating `test`;
extractUpdateColumns correctly returned no `test`-table columns;
doGenerate emitted invalid `... ON DUPLICATE KEY UPDATE ;` for `test`.
Fix: align updateMutatesTable's unqualified-column resolution with
extractUpdateColumns's (which already correctly checks normalColumns
for the target). Refactor:
1. New getNormalColumnsLower helper fetches the target table's
regular column set as a lowercased map[string]bool.
2. GenerateRestoreSQL fetches once at the top (after sourceDatabase
is resolved) and plumbs through extractStatement, findMatchingDMLs,
containsTable, and updateMutatesTable.
3. updateMutatesTable's unqualified branch checks the column against
the target column set. Non-target columns no longer trigger a
match.
Single-table UPDATEs with unqualified SETs (the common case, e.g.
`UPDATE test SET a = 1`) continue to work — `a` is in target's
normal columns.
Trade-off: one additional metadata fetch per GenerateRestoreSQL call
(classifyColumns and hasDisjointUniqueKey already each fetch
metadata). Could be optimized later by hoisting all three behind a
single fetch.
Two regression tests:
- TestGenerateRestoreSQLUnqualifiedSetNonTargetColumn: pins the
bug — unqualified SET on a column not on the target produces
"no DML statement found" error (correct), not invalid empty
ODKU SQL.
- TestGenerateRestoreSQLUnqualifiedSetTargetColumn: pins the
positive path — single-table UPDATE with unqualified SET on a
target column still generates the correct ODKU.
Mysql analog (mysql/restore.go) has the same updateMutatesTable
shape via its containsTable fix; symmetric fix needed; tracked in
BYT-9526.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments