asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Jacobs <sjaco...@ucr.edu>
Subject Re: Nonpure functions in the context of SQL++
Date Wed, 19 Apr 2017 17:18:56 GMT
Thanks!
Steven

On Wed, Apr 19, 2017 at 9:46 AM, Yingyi Bu <buyingyi@gmail.com> wrote:

> Hi Steven,
>
>      As a temporary workaround, you can do the following before your query:
>      SET inline_with = "false"
>
>      If you want to fix this, please take a look at
> InlineWithExpressionVisitor.
>
>      What you can do is to not inline if there is a non-pure function call
> in the expression.
>
>      In addition, please use "WITH ..." before SELECT instead of using
> LET.  LET before SELECT will soon be disabled.
>
> Best,
> Yingyi
>
>
> On Tue, Apr 18, 2017 at 1:33 PM, Steven Jacobs <sjaco002@ucr.edu> wrote:
>
> > I realized that putting it first in the list of from might make sense,
> but
> > it's unclear to me how to make it be treated as a value rather than a
> > sequence in this case, e.g. I tried the following:
> > insert into channels.EmergencyChannelResults as a (
> > select result, channelExecutionTime, sub.subscriptionId as
> > subscriptionId,current_datetime() as deliveryTime
> > from current_datetime()  channelExecutionTime, Metadata.Broker b,
> > channels.EmergencyChannelSubscriptions sub, channels.
> > RecentEmergenciesNearUser(sub.param0) result
> > where b.BrokerName= sub.BrokerName and b.DataverseName= sub.DataverseName
> > ) returning a;
> >
> > But this gives me an error for trying to treat the value as a collection,
> > i.e.
> >
> > unnest $$0 <- function-call: asterix:scan-collection,
> Args:[function-call:
> > asterix:current-datetime, Args:[]] -- |UNPARTITIONED|
> >
> > Steven
> >
> > On Tue, Apr 18, 2017 at 1:23 PM, Steven Jacobs <sjaco002@ucr.edu> wrote:
> >
> >> Hi all,
> >> I'm currently trying to switch the BAD project to SQL++, and having an
> >> issue with non pure function calls. In AQL, a let non-pure assignment
> (e.g.
> >> current-time) before a for statement means that the assignment should
> >> return a single value for all uses under the for. I optimized the
> rewrite
> >> rules to handle this case (The assignment will start out above an
> >> empty-tuple-source, meaning that it's called once in the initial plan).
> >>
> >> In SQL++, the last statement isn't true. If you do a let assignment
> >> before a select, the assignment starts out baked into the result object
> >> constructor, which means that it starts out inherently being called on a
> >> per-result-object basis.
> >>
> >> It's unclear to me how this stuff should be handled in SQL++ syntax. Is
> >> there an inherent way to tell the parser that a "let" should be done
> only
> >> once?
> >>
> >> Steven
> >>
> >
> >
>

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