CTE parsing fails when name is a non-reserved keyword
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 65/100
Rechercherichtung
Beginne damit, die beiden vendor/bin/sql-parser --lint --query-Reproduzenten auszuführen, und verfolge, wie Lexer und Parser den CTE-Namen nach WITH behandeln, einschließlich mit Backticks in Anführungszeichen gesetzter Namen. Als erledigt gilt die Aufgabe, wenn beide Abfragen erfolgreich geparst werden, einschließlich Namen von nicht reservierten Schlüsselwörtern und in Anführungszeichen gesetzter Schlüsselwortnamen, ohne die gemeldeten Fehler.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- PHP
- Sterne
- 485
- Forks
- 119
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
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 phpmyadmin/sql-parser
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
phpmyadmin/sql-parser#655 · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
phpmyadmin/sql-parser#666 ·
-
kind/support
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
phpmyadmin/sql-parser#653 · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 70/100
phpmyadmin/sql-parser#649 ·
-
bug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 25/100
phpmyadmin/sql-parser#643 · 1 Kommentar ·
Alle Issues in phpmyadmin/sql-parser
Ähnliche Issues
-
tooling
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
UX
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
ProfessionalWiki/NeoWiki#1525 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
OpenConext/OpenConext-engineblock#2122 ·
-
Bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
Automattic/safe-publish#594 ·