Not sure, but I don't think this is (nearly) sufficient context/info to
see what's going on. With the current factoring of things, any other
place that includes Expression is not going to allow a SelectExpression
to appear directly as an Expression. Your change would - which might be
a major change, syntactically, that might lead to a variety of
ambiguities. Without looking at the whole grammar one can't tell. I
would guess that if you look, you may find that you can have a
SelectExpression as a query if and only if its enclosed in parentheses,
which might be by design to avoid ambiguities. Have a look at that....
(Basically, look at the other uses of Expression in the grammar - and/or
look to see if "(" SelectExpression ")" is permitted if you follow
through the grammar from Expression.
On 3/14/18 8:59 PM, Xikui Wang wrote:
Dear Devs,
I'm trying to fix a compilation issue with the subquery in SQLPP and got a
question about the specification of "Expression". Here is the current
grammar of "Query" and "Expression" in SQLPP:
Query::=( Expression | SelectExpression )
Expression::=( OperatorExpr | CaseExpr | QuantifiedExpression )
I'm wondering why "SelectExpression" is not in the specification of
"Expression" but in "Query". When I looked back to the AQL specification, I
found that we have:
Query::=Expression
Expression::=( OperatorExpr | IfThenElse | FLWOGR | QuantifiedExpression )
If this specification in SQLPP is not intentionally designed, can we change
it to this:
Query::=( Expression )
Expression::=( OperatorExpr | CaseExpr | QuantifiedExpression |
SelectExpression ) ?
As the Subquery are handled separately in the parenthesized expression
part, the "SelectExpression" here is non-subquery by default.
Any thoughts? Thanks!
Best,
Xikui
