fix: reject unsupported DELETE LIMIT

[ryux1]

Which issue does this PR close?

• Part of BUG: DELETE with a LIMIT clause ignores the LIMIT and deletes every matching row #24998; this PR adds a safe rejection until bounded DELETE is implemented.

Rationale for this change

DELETE with LIMIT currently appears to plan successfully, but the table provider receives only the filters and deletes every matching row. Rejecting the unsupported clause prevents a bounded delete from silently becoming an unbounded one and matches the existing UPDATE LIMIT behavior.

What changes are included in this PR?

• reject DELETE LIMIT during SQL planning
• remove the unreachable limit construction from delete_to_plan
• replace the misleading EXPLAIN snapshots with error regressions, both with and without WHERE
• directly cover both planner rejection branches in the SQL integration suite

What is the testing strategy for this PR?

• cargo test -p datafusion-sqllogictest --test sqllogictests -- delete
• cargo test -p datafusion-sql --lib (88 passed)
• cargo test -p datafusion-sql --test sql_integration plan_delete_rejects_limit (2 passed)
• cargo clippy -p datafusion-sql --all-targets -- -D warnings
• cargo fmt --all -- --check

Are there any user-facing changes?

Yes. DELETE statements containing LIMIT now return a not-implemented planning error instead of accepting the limit and potentially deleting every matching row. There is no public Rust API change.

Implementation and validation were completed with AI coding assistance under the account owner’s direction.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.90%. Comparing base (f2b2ffd) to head (ae0f716).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #25005      +/-   ##
==========================================
- Coverage   81.90%   81.90%   -0.01%     
==========================================
  Files        1134     1134              
  Lines      425156   425151       -5     
  Branches   425156   425151       -5     
==========================================
- Hits       348234   348217      -17     
- Misses      56281    56292      +11     
- Partials    20641    20642       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[martin-g]

Should this PR really close the issue ?
IMO the issue should stay opened until a support for limiting the number of deleted rows is implemented.
This PR is a good improvement that should be applied until the proper support is implemented.

[ryux1]

Agreed—the issue should remain open for full bounded DELETE support. I updated the PR description so this no longer closes #24998.

[ryux1]

The only remaining failing check is cargo test hash collisions (amd64), which timed out at the six-hour runner limit; the rest of the matrix is green and the PR is approved. I tried to rerun the failed job, but GitHub reserves reruns here for repository admins. Could a maintainer rerun that job when convenient?

[alamb]

Thank you @ryux1 and @martin-g -- I put this in the merge queue after merging up from main

[alamb]

Thank you for the contribution @ryux1 and @martin-g

However, I am not sure about this one

DELETE with LIMIT currently appears to plan successfully, but the table provider receives only the filters and deletes every matching row. Rejecting the unsupported clause prevents a bounded delete from silently becoming an unbounded one and matches the existing UPDATE LIMIT behavior.

Can you please provide a reproducer that shows this bug behavior? The code in this PR appears to show a limt passed to the input.

It seems like maybe your problem is somewhere else , but just forbidding such deletes and removing the planning code doesn't see right 🤔