`SHOW TABLES ... LIKE 'p' LIMIT n` is displayed with the `LIKE` after `LIMIT`
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- Ein halber Tag
- Anfängerfreundlichkeit
- 62/100
Rechercherichtung
Start with parse_show_stmt_options in the parser, where the suffix LIKE filter is read right after show_in, then compare it with Display for ShowStatementOptions, which writes the fields in a different order. Check the round-trip tests for SHOW TABLES and SHOW DATABASES with a ClickHouseDialect. Done when SHOW TABLES FROM system LIKE '%user%' LIMIT 2 displays in the same order it was parsed and reparses with the filter intact, and the Snowflake infix case still round-trips.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
With dialects that take the LIKE filter as a suffix (ClickHouse, MySQL, Generic, ...), Display writes it after LIMIT, and the output reparses as a LIKE inside the limit expression:
SHOW TABLES FROM system LIKE '%user%' LIMIT 2 (ClickHouseDialect)
-> displays as: SHOW TABLES FROM system LIMIT 2 LIKE '%user%'
-> reparses with LIMIT (2 LIKE '%user%') and no filter
SHOW DATABASES LIKE '%de%' LIMIT 2
-> displays as: SHOW DATABASES LIMIT 2 LIKE '%de%' (same AST change)
SHOW TABLES LIKE 'x%' LIMIT 2 (SnowflakeDialect, infix filter)
-> round-trips (fine)
ClickHouse puts the pattern before LIMIT: SHOW [FULL] [TEMPORARY] TABLES [{FROM | IN} <db>] [[NOT] LIKE | ILIKE '<pattern>'] [LIMIT <N>] ... (https://clickhouse.com/docs/sql-reference/statements/show).
parse_show_stmt_options reads the suffix filter right after show_in, before STARTS WITH / LIMIT / FROM, but Display for ShowStatementOptions uses "{like_in_infix}{show_in}{starts_with}{limit}{from}{like_in_suffix}".
Tested on main ce12f1f6 (also 0.63.0 and 0.58.0).
Found with a property-based fuzzer (round trip check); I used AI assistance for triage and verified every case above.
- Vorherrschende Sprache
- Rust
- Sterne
- 3.5k
- Forks
- 805
- Ø Merge
- 2 T. 3 Std.
- Gemergte PRs (30 T.)
- 116
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/datafusion-sqlparser-rs
-
Redshift
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
apache/datafusion-sqlparser-rs#2959 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Redshift
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
apache/datafusion-sqlparser-rs#2958 ·
Maintainer antworten meist innerhalb von 1 Tag
-
PostgreSQL
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
apache/datafusion-sqlparser-rs#2862 ·
Maintainer antworten meist innerhalb von 1 Tag
-
PostgreSQL
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
apache/datafusion-sqlparser-rs#2861 ·
Maintainer antworten meist innerhalb von 1 Tag
-
PostgreSQL
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 77/100
apache/datafusion-sqlparser-rs#2858 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in apache/datafusion-sqlparser-rs
Ähnliche Issues
-
area:schema documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
ElectronicWave/Elemental#252 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
dekobon/big-code-analysis#1887 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Shell中文符号输入异常Offenbug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag