`SHOW TABLES ... LIKE 'p' LIMIT n` is displayed with the `LIKE` after `LIMIT`
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 62/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Rust
- Estrellas
- 3.5k
- Forks
- 805
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 116
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/datafusion-sqlparser-rs
-
Redshift
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/datafusion-sqlparser-rs#2959 ·
Los mantenedores suelen responder en 1 día
-
Redshift
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apache/datafusion-sqlparser-rs#2958 ·
Los mantenedores suelen responder en 1 día
-
PostgreSQL
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apache/datafusion-sqlparser-rs#2862 ·
Los mantenedores suelen responder en 1 día
-
PostgreSQL
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apache/datafusion-sqlparser-rs#2861 ·
Los mantenedores suelen responder en 1 día
-
PostgreSQL
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
apache/datafusion-sqlparser-rs#2858 ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/datafusion-sqlparser-rs
Issues similares
-
area:schema documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
ElectronicWave/Elemental#252 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dekobon/big-code-analysis#1887 ·
Los mantenedores suelen responder en 1 día
-
Shell中文符号输入异常Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día