rusackas opened a new pull request, #42588: URL: https://github.com/apache/superset/pull/42588
### SUMMARY This is a **test-only PR** opened as a TDD-style validation of issue #36939. #36939 (filed 2026-01) reports that several StarRocks-specific SQL statements fail in SQL Lab. The reporter's actual error messages split this into two unrelated bugs: 1. `SHOW TABLES`, `SHOW DATABASES`, `SHOW CREATE TABLE ...` fail with `Unexpected input 'LIMIT'`. This is a genuine Superset bug: `SQLStatement.set_limit_value`'s `FORCE_LIMIT` path unconditionally sets `_parsed.args["limit"]` regardless of statement type. sqlglot's `Show` expression has no real `LIMIT` slot, so instead of rejecting cleanly it renders a malformed statement with the `LIMIT` keyword twice (verified directly: `SHOW TABLES` → `'SHOW TABLES LIMIT \nLIMIT 1000'`). StarRocks (and presumably other `FORCE_LIMIT` engines) reject that outright. 2. `REFRESH EXTERNAL TABLE ...` and `DROP TABLE ... FORCE` fail with a genuine sqlglot `ParseError`. Verified directly against the pinned sqlglot version (30.12.0): this is an upstream dialect gap, not something fixable in this repo, and it reproduces the same way for every dialect I tried, not just `starrocks`. Out of scope for a Superset-side fix/test. This PR adds one regression test on the first bug, the one Superset's own code can actually fix: 1. **`test_set_limit_value_leaves_show_statements_unchanged`** — feeds `SHOW TABLES` / `SHOW DATABASES` / `SHOW CREATE TABLE ...` through `SQLStatement.set_limit_value(1000, LimitMethod.FORCE_LIMIT)` for the `starrocks` engine and asserts the statement comes out unchanged (no `LIMIT` injected). ### How to interpret CI - **CI red (expected)** → confirms the bug: `set_limit_value` still corrupts `SHOW` statements on current `master`. The fix likely belongs in `SQLStatement.set_limit_value` (`superset/sql/parse.py`), guarding the `FORCE_LIMIT` branch against `isinstance(self._parsed, exp.Show)` (or more generally, any statement type without a meaningful `LIMIT` slot). A community member already sketched this exact guard in the issue thread. - **CI green** → would mean the guard already exists and this reproduces clean; I did not observe that locally (ran it directly against current `master`, all 3 parametrized cases fail). ### TESTING INSTRUCTIONS ```bash pytest tests/unit_tests/sql/parse_tests.py -k test_set_limit_value_leaves_show_statements_unchanged -v ``` ### ADDITIONAL INFORMATION - [x] Has associated issue: validates #36939 (not closing via keyword — this is the confirming test, not the fix) - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration - [ ] Introduces new feature or API - [ ] Removes existing feature or API 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
