Re: Function array_agg(array) - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Function array_agg(array)
Date
Msg-id CAFj8pRApxKMi0zDg+q6TcE+4ZQQ8uE8tgydkS3jYGLTQ1_JKXQ@mail.gmail.com
Whole thread Raw
In response to Re: Function array_agg(array)  (Ali Akbar <the.apaan@gmail.com>)
Responses Re: Function array_agg(array)
List pgsql-hackers
Hi

2014-10-19 8:02 GMT+02:00 Ali Akbar <the.apaan@gmail.com>:
So, is there any idea how we will handle NULL and empty array in array_agg(anyarray)? 
I propose we just reject those input because the output will make no sense:
- array_agg(NULL::int[]) --> the result will be indistinguished from array_agg of NULL ints.
- array_agg('{}'::int[]) --> how we determine the dimension of the result? is it 0? Or the result will be just an empty array {} ?

This updated patch rejects NULL and {} arrays as noted above.
 

I agree with your proposal. I have a few comments to design:

1. patch doesn't hold documentation and regress tests, please append it.

2. this functionality (multidimensional aggregation) can be interesting more times, so maybe some interface like array builder should be preferred.

3. array_agg was consistent with array(subselect), so it should be fixed too

postgres=# select array_agg(a) from test;
       array_agg      
-----------------------
 {{1,2,3,4},{1,2,3,4}}
(1 row)

postgres=# select array(select a from test);
ERROR:  could not find array type for data type integer[]

4. why you use a magic constant (64) there?

+         astate->abytes = 64 * (ndatabytes == 0 ? 1 : ndatabytes);
+         astate->aitems = 64 * nitems;

+             astate->nullbitmap = (bits8 *)
+                 repalloc(astate->nullbitmap, (astate->aitems + 7) / 8);

Regards

Pavel

 
Regards,
--
Ali Akbar


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_receivexlog --status-interval add fsync feedback
Next
From: Tom Lane
Date:
Subject: Re: Reducing lock strength of adding foreign keys