asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <>
Subject Re: Nonpure functions in the context of SQL++
Date Wed, 19 Apr 2017 16:46:01 GMT
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

     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.


On Tue, Apr 18, 2017 at 1:33 PM, Steven Jacobs <> 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 <> 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

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