phpmyadmin / phpmyadmin/sql-parser

CTE parsing fails when name is a non-reserved keyword

Abierto
#662 0 comentarios 2 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
PHP
Estrellas
485
Forks
119
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

The parser rejects valid CTEs whose names are non-reserved keywords, throwing:

The name of the CTE was expected.

MySQL has a large set of keywords that are explicitly not reserved (no (R) marker in the official MySQL 9.7 keyword list^1). Non-reserved keywords are explicitly permitted as unquoted identifiers, including CTE names. MySQL executes these queries without error^2.

Reproducer

Unquoted:
vendor/bin/sql-parser --lint --query "WITH data AS (SELECT 1) SELECT * FROM data"
#1: The name of the CTE was expected. (near "data" at position 5)
#2: Unexpected end of the WITH CTE. (near "data" at position 5)
#3: Unrecognized statement type. (near "data" at position 5)
Backtick-quoted (which should unconditionally allow any keyword as an identifier):
vendor/bin/sql-parser --lint --query "WITH `data` AS (SELECT 1) SELECT * FROM `data`"
#1: The name of the CTE was expected. (near "`data`" at position 5)
#2: Unexpected end of the WITH CTE. (near "`data`" at position 5)
#3: Unexpected beginning of statement. (near "`data`" at position 5)
#4: Unrecognized statement type. (near "AS" at position 12)

Expected behaviour

The query parses successfully for any non-reserved keyword used as a CTE name, whether unquoted or backtick-quoted.

Actual behaviour

Parser throws errors in both cases. The root cause appears to be that the lexer classifies all keywords as keyword tokens unconditionally, rather than resolving them contextually. After WITH, the parser expects an identifier token; receiving a keyword token instead, it fails, even though MySQL allows non-reserved keywords in identifier position without quoting, and allows any keyword in identifier position when backtick-quoted.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza ejecutando los dos reproductores vendor/bin/sql-parser --lint --query y sigue cómo el lexer y el parser gestionan el nombre del CTE después de WITH, incluidos los nombres entre comillas invertidas. Se considera terminado cuando ambas consultas se analicen correctamente, incluidos los nombres de palabras clave no reservadas y los nombres de palabras clave entre comillas, sin los errores indicados.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
mysql, php, sql
Área
compilers, databases
Tipo de issue
Error
Dificultad
3/5
Tiempo estimado
1-2 días
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
65/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.