You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Xikui Wang <xi...@uci.edu> on 2018/03/15 03:59:45 UTC
Specification of "Expression" in SQLPP
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
Re: Specification of "Expression" in SQLPP
Posted by Xikui Wang <xi...@uci.edu>.
The patch is under review now. :)
Best,
Xikui
On Thu, Mar 15, 2018 at 8:47 PM, Mike Carey <dt...@gmail.com> 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 <
> dmitry.lychagin@couchbase.com>
> 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" <xi...@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" <dt...@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
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
Re: Specification of "Expression" in SQLPP
Posted by Mike Carey <dt...@gmail.com>.
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 <dm...@couchbase.com>
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" <xi...@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" <dt...@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
> > >
> >
> >
> >
> >
>
>
>
Re: Specification of "Expression" in SQLPP
Posted by Dmitry Lychagin <dm...@couchbase.com>.
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" <xi...@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" <dt...@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
> >
>
>
>
>
Re: Specification of "Expression" in SQLPP
Posted by Xikui Wang <xi...@uci.edu>.
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" <dt...@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
> >
>
>
>
>
Re: Specification of "Expression" in SQLPP
Posted by Dmitry Lychagin <dm...@couchbase.com>.
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" <dt...@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
>
Re: Specification of "Expression" in SQLPP
Posted by Mike Carey <dt...@gmail.com>.
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
>