test(advisor/tidb): pin cumulative #24 — UNION outer-ORDER-BY UX impr… · bytebase/bytebase@85d77b2 · GitHub
Skip to content

Commit 85d77b2

Browse files
vsai12claude
andcommitted
test(advisor/tidb): pin cumulative #24 — UNION outer-ORDER-BY UX improvement on insert_disallow_order_by_rand
Peer review caught a silent behavior change at the UNION boundary that the initial batch 14 PR description elided. Pre-omni pingcap-tidb's `InsertStmt.Select` is a `ResultSetNode` interface. For `INSERT INTO t SELECT ... UNION SELECT ... ORDER BY RAND()` the concrete type is `*ast.SetOprStmt`, NOT `*ast.SelectStmt`. The pre-omni Enter's `insert.Select.(*ast.SelectStmt)` cast failed and the whole check was silently skipped — pre-omni rule did NOT flag UNION-result ORDER BY RAND despite the rule's name and stated intent. Omni's `InsertStmt.Select` is `*SelectStmt` (concrete pointer) regardless of SetOp value; UNION'd inputs surface as `SelectStmt{SetOp: SetOpUnion, Left: ..., Right: ..., OrderBy: [...]}`. Direct access to `ins.Select.OrderBy` lands on the outer-UNION ORDER BY list. Rule now fires — silent UX improvement matching the rule's actual intent. Same UX-improvement shape as cumulative #18 ("is text" advice content fix) and #21 (latent BLOB MODIFY false-positive). Verified empirically by parsing the same input through both pingcap- and omni-tidb parsers and inspecting `%T` / `SetOp` / `OrderBy[0]`. Updates: - Advisor comment now accurately describes outer-vs-inner UNION boundary distinction (outer-UNION OrderBy newly covered; per-arm parenthesized OrderBy remains uncovered — omni rejects that syntax in INSERT position, separate Phase 2 grammar gap). - New positive fixture pin asserting the rule fires on the un-parenthesized UNION form. NEW pre-batch audit axis added in plan-doc cumulative #24: when pingcap source uses a narrow type-assertion on an interface-typed field (e.g. `.(*ast.SelectStmt)` on `ResultSetNode`), the omni port may newly reach inputs the old code accidentally filtered out — the omni equivalent field is often concrete-typed, so direct access bypasses the implicit filter. Audit every type-assertion: ask "does this assertion narrow the input set?" Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent cbac08e commit 85d77b2

2 files changed

Lines changed: 39 additions & 12 deletions

File tree

‎backend/plugin/advisor/tidb/advisor_insert_disallow_order_by_rand.go‎

Lines changed: 15 additions & 12 deletions

‎backend/plugin/advisor/tidb/test/statement_insert_disallow_order_by_rand.yaml‎

Lines changed: 24 additions & 0 deletions

0 commit comments

Comments
 (0)