asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Lychagin <dmitry.lycha...@couchbase.com>
Subject Re: Specification of "Expression" in SQLPP
Date Thu, 15 Mar 2018 20:19:26 GMT
Xikui,

Right, seems like we could change the FunctionDeclaration production to include SelectExpression
as you suggested.

Thanks,
-- Dmitry
 
´╗┐On 3/15/18, 12:16 PM, "Xikui Wang" <xikuiw@uci.edu> wrote:

    The issue that I'm looking at is about UDF specification. Currently, we use
    this:
    
    FunctionDeclaration::=<DECLARE> <FUNCTION> Identifier ParameterList
    <LEFTBRACE> Expression <RIGHTBRACE>,
    
    which enforces the "SelectExpression" to be put into parentheses so it can
    be matched by "OperatorExpr" (see the specification of Expression in my
    previous email). This I think probably is not necessary. Similar syntax
    without explicit parentheses is available in AQL. There was a test case for
    this and it's disabled for now.
    
    As suggested by Mike, I went through the usages of "Expression". I guess
    the separation is to make sure all "SelectExpression"s are parenthesized if
    it's not a top-level query. For that purpose, maybe I can change the
    Function Declaration to this:
    
    FunctionDeclaration::=<DECLARE> <FUNCTION> Identifier ParameterList
    <LEFTBRACE> SelectExpression | Expression <RIGHTBRACE>  ?
    
    Best,
    Xikui
    
    On Thu, Mar 15, 2018 at 10:45 AM, Dmitry Lychagin <
    dmitry.lychagin@couchbase.com> wrote:
    
    > Xikui,
    >
    > "(" SelectExpression ")" is permitted by the Subquery() production, and
    > Subquery() itself is one of the alternatives in the
    > ParenthesizedExpression().
    >
    > What is the compilation issue you were trying to solve?
    >
    > Thanks,
    > -- Dmitry
    >
    > On 3/14/18, 11:52 PM, "Mike Carey" <dtabass@gmail.com> wrote:
    >
    >     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
View raw message