asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Specification of "Expression" in SQLPP
Date Thu, 15 Mar 2018 06:52:38 GMT
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
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message