Re: Row pattern recognition

Hi Tatsuo,

> I will look into these after finishing post patch release review for
> v51.

Before you start, one thing has changed under us. SQL/PGQ was
reverted from master yesterday (b1f106c80cb). Rebasing v51 and the
increment onto current master raises a handful of conflicts, all
mechanical, and then breaks on something that raised none.

The conflicts first. Five hunks in three commits, all of the same
shape: SQL/PGQ had added something, RPR added its own entry next to
it, and the revert took the SQL/PGQ half away.

gram.y the %type block, the keyword token list (DESTINATION
next to our DEFINE), and the %nonassoc list before
%left Op OPERATOR
parse_agg.c EXPR_KIND_PROPGRAPH_PROPERTY next to
EXPR_KIND_RPR_DEFINE
parse_expr.c the same
nodeFuncs.c T_GraphElementPattern and T_GraphPattern next to
T_RPCommonSyntax and T_RPRPatternNode

In each, the resolution is to keep our side and drop theirs.

"|" is the one that did not announce itself. The lexer change lives
in scan.l, which no RPR commit touches, so it came away with the
revert and raised no conflict at all. RPR still needs it.

Without it a lone "|" arrives as an Op, row_pattern_alt never fires,
and PATTERN (A | B) fails with "unsupported quantifier".

What made it work was SQL/PGQ (2f094e7ac69). It needed a lone "|"
for label disjunction in GRAPH_TABLE, so that an element pattern
could be written as MATCH (a IS vl1 | vl2).

RPR's alternation was then written against that token.
row_pattern_alt does the same thing one level up, and the handling
around it assumes "|" arrives separately. We extended what SQL/PGQ
had put in place, so with SQL/PGQ gone RPR has to carry the
groundwork itself.

The attached nocfbot-0002-pipe-single-character-token.txt does that.

Best regards,
Henson