CTE parsing fails when name is a non-reserved keyword
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 65/100
Piste de recherche
Commencez par exécuter les deux reproducteurs vendor/bin/sql-parser --lint --query et suivez la manière dont le lexer et le parser traitent le nom du CTE après WITH, y compris les noms entre accents graves. C'est terminé lorsque les deux requêtes sont analysées avec succès, y compris les noms de mots-clés non réservés et les noms de mots-clés entre guillemets, sans les erreurs signalées.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- PHP
- Étoiles
- 485
- Forks
- 119
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de phpmyadmin/sql-parser
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
phpmyadmin/sql-parser#655 · 1 réaction ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
phpmyadmin/sql-parser#666 ·
-
MariaDB and MySQL contexts Ouvertekind/support
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
phpmyadmin/sql-parser#653 · 1 réaction ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 70/100
phpmyadmin/sql-parser#649 ·
-
Support `PAGE_COMPRESSED`=1` Ouvertebug
Difficulté 3/5 1-2 jours Accessibilité débutants 25/100
phpmyadmin/sql-parser#643 · 1 commentaire ·
Toutes les issues de phpmyadmin/sql-parser
Issues similaires
-
tooling
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
UX
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
ProfessionalWiki/NeoWiki#1525 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
OpenConext/OpenConext-engineblock#2122 ·
-
Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Automattic/safe-publish#594 ·