Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Subject: Re: Postgres Aggregation Function - Discussion
To: dev@asterixdb.incubator.apache.org
References: 
 <CANSzjP3+qM7rCs8fws0m6gTN5-EcPJdzL_kSJuJfF9zGhB6tgQ@mail.gmail.com>
 <CANSzjP3C=Avj4x=6k1X-2owJHB8OEw-ZXsvp8+UWLrfqEp5tGg@mail.gmail.com>
From: Mike Carey <dtabass@gmail.com>
Message-ID: <564D2C07.1030503@gmail.com>
Date: Wed, 18 Nov 2015 17:55:19 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
 <CANSzjP3C=Avj4x=6k1X-2owJHB8OEw-ZXsvp8+UWLrfqEp5tGg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------010109070807060403070309"

--------------010109070807060403070309
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

James,

We all need to look at this!!!  Sorry sorry sorry!  I will have a look 
ASAP (by early next week, say Tuesday since that's traditionally a "UCR 
day" for me, at the latest).

Question - what do you mean by "do we want a scalar or aggregate 
version" of the functions?  It seems like we don't have a choice, do 
we?  Aren't they inherently aggregate functions (so the answer would be 
the latter)?  I think maybe I didn't get the gist of the question.  On 
the SQL vs. AQL versions - it would be nice to have both versions of 
each (aggregate) function, actually - i.e., one version that does what 
SQL does in terms of turning a blind eye to nulls, and one version that 
does what AQL does, which is to say that if you have a null (a.k.a. 
unknown) input then the output must logically be unknown as well (e.g., 
if you add two numbers by either doing "+" or having them appear in a 
two-object dataset's numeric column and doing sum( ), you should get the 
same answer either way).

More to follow when I look more closely!  Sorry we've all been so slow.  
(@Others: your take(s)?)

Cheers,
Mike


On 11/18/15 2:06 PM, James Fang wrote:
> Just wondering if anyone has a response on this discussion?
>
> Thanks,
> James
>
> On Mon, Nov 9, 2015 at 2:11 PM, James Fang <jfang003@ucr.edu> wrote:
>
>> The following functions that I am asking about are from
>> http://www.postgresql.org/docs/9.4/static/functions-aggregate.html
>>
>> The following google doc contains a spreadsheet of all the current
>> aggregation functions that exist in AQL and SQL. The colored portions will
>> be the portions that I wish to discuss. I assumed that AQL returns null if
>> at least 1 of the results in the aggregation is null while SQL ignores the
>> tuple if it is null.
>>
>> https://docs.google.com/document/d/1l9QtRAB7H3yzP3976livpKzJZHVJlPdvDrjlm2YCsM0/edit?usp=sharing
>>
>> Questions:
>> 1) Do we need array_agg, this function just groups up the results together
>> into one array as output. If so, do we want a scalar version or aggregate
>> version?
>> 2) For bitwise-or and bitwise-and, I have implemented a sql aggregate
>> version. Do we want a AQL aggregate version as well? Do you think that we
>> should implement this as a scalar or as an aggregation?
>> 3) For boolean-or and boolean and, we current have an existing scalar
>> version for AQL. Do we need a scalar version for SQL? Should we implement a
>> aggregate version of these boolean functions?
>> 4) Do we need a json_agg function? I do not think so because all the data
>> is returned in json format. If you have a different answer, let me know.
>> 5) For string_agg, we currently have a scalar version for AQL known as
>> string-join. Do we need a SQL version?
>>


--------------010109070807060403070309--