The patch is under review now. :)

Best,
Xikui

On Thu, Mar 15, 2018 at 8:47 PM, Mike Carey <[email protected]> wrote:

> Let's do it!  No issues for the rewrite step that follows when inlining,
> hopefully?
>
> On Thu, Mar 15, 2018, 1:19 PM Dmitry Lychagin <
> [email protected]>
> wrote:
>
> > 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" <[email protected]> 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 <
> >     [email protected]> 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" <[email protected]> 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
> >     >     >
> >     >
> >     >
> >     >
> >     >
> >
> >
> >
>

Reply via email to