Cypher keyword-named aliases cannot be referenced back as variables

[crprashant]

Followup: keyword-named aliases cannot be referenced back

After #2415 lands, safe_keywords (e.g. count, exists, coalesce,
match, where, order, limit, distinct, ...) are accepted as
aliases in RETURN/WITH/YIELD/UNWIND ... AS <name>. However,
once such an alias is bound, it still cannot be referenced as a
variable later in the same query.

Reproducer (against the branch from #2415)

SELECT * FROM cypher('g', $$ WITH 1 AS count RETURN count $$) AS (a agtype);
-- ERROR:  syntax error at end of input

SELECT * FROM cypher('g', $$ UNWIND [1,2,3] AS count RETURN count $$) AS (a agtype);
-- ERROR:  syntax error at end of input

SELECT * FROM cypher('g', $$ WITH 5 AS limit RETURN limit + 1 AS x $$) AS (a agtype);
-- ERROR:  syntax error at or near "+"

The alias binds successfully (so projecting any literal under
AS count works), but the parser cannot reduce a bare COUNT token to
an expr_var, so the second mention of count fails.

Root cause

expr_var: var_name reads the variable through var_name, which still
accepts only symbolic_name (i.e. IDENTIFIER). #2415 deliberately
broadens only the alias-binding path (var_name_alias) because
broadening var_name itself reintroduces ~156 shift/reduce conflicts
in bison (keyword tokens collide with their syntactic roles inside
expressions and patterns).

A complete fix likely requires either:

1. A scoped grammar refactor that resolves the conflicts (probably with
   precedence directives or a hand-written lookahead helper), or
2. Lexer-level handling that re-tags an already-bound alias name as
   IDENTIFIER for the rest of the query (rejected by Apache AGE
   before — context-sensitive lexing), or
3. A semantic-analysis pass that rewrites expr_var references to
   safe_keywords before parsing reaches the conflict (intrusive).

Workaround today

Use a plain identifier when the alias needs to be referenced:

SELECT * FROM cypher('g',
    $$ WITH 1 AS cnt RETURN cnt $$
) AS (a agtype);

or backtick-quote the alias if the keyword form is desired downstream:

SELECT * FROM cypher('g',
    $$ WITH 1 AS `count` RETURN `count` $$
) AS (a agtype);

Related

• Usind reserved keywords as aliases in Cypher queries #2355 — original report (alias binding, fixed in Allow safe Cypher reserved keywords in alias positions (#2355) #2415).
• Allow safe Cypher reserved keywords in alias positions (#2355) #2415 — alias-binding fix; this issue tracks the remaining
  read-back asymmetry.

[jrgemignani]

@crprashant Not sure if this issue was resolved or not,...

[crprashant]

Not resolved. #2415 fixed only the alias-binding side (... AS count works). Reading a keyword-named alias back (WITH 1 AS count RETURN count) still errors, because expr_var reads through var_name, which only accepts IDENTIFIER (symbolic_name). This was left intentionally in #2415, since broadening expr_var to accept safe_keywords reintroduces ~156 shift/reduce conflicts in bison.

The grammar comment in src/backend/parser/cypher_gram.y documents this asymmetry (writable but not readable) and points to this issue as tracking the remaining work. So #2416 should stay open.

[jrgemignani]

@crprashant But, if this is true, then is it solvable?

This was left intentionally in #2415, since broadening expr_var to accept safe_keywords reintroduces ~156 shift/reduce conflicts in bison.

[crprashant]

Yes, it's solvable -- the ~156 conflicts are a symptom of these keywords doing double duty in expression position, not a hard wall:

• operator keywords (AND/OR/NOT/XOR/IS/IN/CONTAINS/STARTS/ENDS, CASE/WHEN/THEN/ELSE) collide with their operator roles;
• COUNT/EXISTS/COALESCE collide with their dedicated keyword(...) expression syntax;
• clause keywords (WITH/RETURN/ORDER/LIMIT/...) collide with clause boundaries after an expression.

The clean fix is the PostgreSQL approach: split keywords into reserved/unreserved categories and factor the expression + identifier grammar so non-reserved words reduce to an identifier without conflict (option 1 in the issue description). A GLR parser would also work but is a bigger architectural change, and context-sensitive lexing (re-tagging a bound alias as IDENTIFIER) was previously rejected for AGE.

So it's doable, just not a small patch -- the count/exists/coalesce family is the thorniest, since they own expression syntax. Keeping this open as a tracked enhancement seems right.