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

From Ali Akbar
Subject Re: Function array_agg(array)
Date
Msg-id CACQjQLqwadsE=L797yLygd9nbLJD4FL-S5Cuiy_90FSWMdgZ4g@mail.gmail.com
Whole thread Raw
In response to Re: Function array_agg(array)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Function array_agg(array)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2014-11-26 0:38 GMT+07:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2014-10-27 11:20 GMT+01:00 Ali Akbar <the.apaan@gmail.com>:
>> [ array_agg_anyarray-13.patch ]

> This patch is ready for commit

I've committed this after some significant modifications.

I did not like the API chosen, specifically the business about callers
needing to deal with both accumArrayResult and accumMdArray, because that
seemed pretty messy and error-prone. 

Thanks!

When in the reviewing process, we tried to implement in existing API, and it was messy, so the last patch is with two API. We didn't think what you eventually did. 3 API: existing for scalar, a new API for array, _and_ a new API for both. Great!!

Just curious, in accumArrayResultArr, while enlarging array and nullbitmaps, why it's implemented with:

astate->abytes = Max(astate->abytes * 2,
                                 astate->nbytes + ndatabytes);

and 

astate->aitems = Max(astate->aitems * 2, newnitems);

won't it be more consistent if it's implemented just like in the first allocation?:

while (astate->aitems <= newnitems)
                            astate->aitems *= 2;

Anyway, thanks for the big modifications. I learned a lot from that.

Regards,
--
Ali Akbar

pgsql-hackers by date:

Previous
From: Adam Brightwell
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation
Next
From: Tom Lane
Date:
Subject: Re: Function array_agg(array)