Repository navigation
Conversation
GenericDialect (and other dialects that do not support DELETE+LIMIT) previously accepted `DELETE ... LIMIT n`, so engines like DataFusion that use GenericDialect silently ignored the LIMIT. Add Dialect::supports_delete_limit() (default false), enable it for MySQL and SQLite, and only parse LIMIT in DELETE when the dialect opts in. Closes apache#2615. Signed-off-by: Vincent <ump45nose@users.noreply.github.com>
ump45nose
force-pushed
the
fix/2615-delete-limit-dialect-gate
branch
from
October 29, 2026 13:31
9e1120b to
a8e93b0
Compare
Author
|
Rebased onto latest (AI-assisted reply.) |
zvonimir-dd
reviewed
Oct 30, 2026
zvonimir-dd
left a comment
zvonimir-dd
left a comment
Contributor
There was a problem hiding this comment.
Thanks for picking this up. I'm not sure gating Generic off is the right fix, though, and it might be worth a maintainer weighing in on #2615 first:
GenericDialectusually opts in to permissive syntax. The closest precedent,supports_update_order_by(), returnstruefor Generic as well as MySQL. With this PR, Generic users parsing MySQL-flavoured SQL get a new parse error, which makes this a breaking change.- The DataFusion bug behind #2615 is already fixed on the DataFusion side: apache/datafusion#25005 (merged 2026-10-08) rejects
DELETE ... LIMITduring planning, and describes that as temporary until bounded DELETE is implemented. Keepinglimitin Generic's AST lets DataFusion add that support later without a parser change.
If the flag stays, I'd enable it for GenericDialect as supports_update_order_by does, and call out the behavior change for the remaining dialects in the description/changelog.
| vec![] | ||
| }; | ||
| let limit = if self.parse_keyword(Keyword::LIMIT) { | ||
| let limit = if self.dialect.supports_delete_limit() && self.parse_keyword(Keyword::LIMIT) { |
Contributor
There was a problem hiding this comment.
DELETE ... ORDER BY, parsed a few lines above, is also MySQL/SQLite-only but stays ungated, so DELETE FROM t ORDER BY a still parses in every dialect. Same for UPDATE ... LIMIT. If we gate on dialect, it would be more consistent to gate these together.
…it-dialect-gate Signed-off-by: Vincent <1729065730@qq.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.
Dialects: MySQL, SQLite, Generic, PostgreSQL, DuckDB
Summary
DELETE ... LIMIT nwas accepted by every dialect, includingGenericDialect.Engines that use Generic (e.g. DataFusion) therefore parsed the LIMIT and then
silently ignored it.
Fix
Dialect::supports_delete_limit()(defaultfalse)LIMITinDELETEonly when the dialect opts inCloses #2615.
Docs:
Test plan
cargo test --all-featurescargo fmt --allcargo clippy --all-targets --all-features -- -D warningsparse_delete_limit_dialect_gated(positive for supporting dialects, reject others)fuzz/fuzz_seeds/mysql_2615_delete_limit.sqlAI assistance
This change was developed with AI assistance (Cursor / Grok Bot). I reviewed
every line of the diff and the test output before opening this PR.