GeezerVison

Fixes a ParseException on JSON paths whose element names are reserved keywords. For example:

INSERT INTO "MY_DB"."MY_SCHEMA"."T" ("c")
SELECT "F"."DATA_VALUE":window::VARCHAR
FROM "MY_DB"."MY_SCHEMA"."RAW_TRACES" AS "F"

Produces error[SqlParseException]: unexpected ":" (DOUBLE_COLON)

Path elements after : were parsed as ordinary column names or expressions. Reserved words such as WINDOW, OUTPUT, FROM and SELECT have no identifier token, so the parser threw. After : a name is mandatory, so any word there is a name, reserved or not.

Changes

The two grammar sites that read a path element (PrimaryExpression and JsonExpression) now go through a new JsonPathElement production. It looks ahead before choosing how to parse:

• isKeywordJsonPathName(): the word after : is a keyword and is not followed by (. It is parsed by the new JsonPathKeyword production, which takes the token as the name. It then continues like a primary expression: further steps, :: casts and the same arithmetic tier as before, including MySQL's lower floor.
• isJsonPathWithKeywordAfterDot(): the path starts with an identifier but reaches a keyword after a ., such as v:a.output or v:a[0].from.x. The expression parser would read that as a qualified column name, which doesn't accept a keyword as a part. A new JsonPathStep production takes the keyword as an element name.

Behaviour that stays the same:

• A word followed by ( stays a function call (v:left(x)).
• Keywords after a . outside a JSON path are still rejected (SELECT t.output still throws).
• Paths with no keywords take the same parsing route as before.

AST links

JsonPathKeyword linked the previous element before building each step, so the last step or cast of a path never got an AST node (for example the cast in v:select::INT, or v:from::INT + 1). ASTNodeCoverageTest didn't catch this because it only walks the SQL test resources. Each step and cast is now linked where it's built.