walterddr commented on a change in pull request #1011: [CALCITE-2721] Support
parsing of DOT + MEMBER_FUNCTION
URL: https://github.com/apache/calcite/pull/1011#discussion_r255345936
##########
File path: core/src/main/codegen/templates/Parser.jj
##########
@@ -3380,6 +3380,70 @@ SqlNode UnsignedNumericLiteralOrParam() :
{ return e; }
}
+/**
+ * Parse a row expression extended after an existing record type row expression
+ */
+SqlNode RowExpressionExtension() :
+{
+ final SqlNode e;
+ String p;
+}
+{
+ (
+ LOOKAHEAD( CompoundIdentifier() <LPAREN>)
Review comment:
unfortunately this doesn't work. I actually tried to eliminate all these by
just having this piece of code, (which I think is the right way to approach)
```
(
e = // Identifier() or CompoundIdentifier()
[
// ... (match <LPAREN> and then parse function arguments)
e = createCall( ...
]
)
```
The actual problem here is that,
1. if using Identifier(), the function hierarchy is not correct. for
example, `foo().complex.function.name(arg1, arg2)` will be resolved as
`((foo().complex).function).name(arg1, arg2)` which should've been
`foo().complex.function.name(arg1, arg2)` according to the JIRA discussion.
2. if using Compoundidentifier(), the following doesn't work:
`foo()."EXPR$1"."EXPR$2"` would not be resolved correctly as the part
`."EXPR$1"."EXPR$2"` is not a valid compound identifier.
One thing I can think of is. there's no way to distinguish the boundary of
`foo().complex.column.complex.function(...)` during parser phase. If we do not
accept complex function name, I think the above solution with simply just
`Identifier()` should work.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
