Re: idea - new aggregates median, listagg - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: idea - new aggregates median, listagg
Date
Msg-id 162867790912160742j15e7eed8l7d6463d495cb0167@mail.gmail.com
Whole thread Raw
In response to Re: idea - new aggregates median, listagg  (Thom Brown <thombrown@gmail.com>)
List pgsql-hackers
2009/12/16 Thom Brown <thombrown@gmail.com>:
> 2009/12/15 Pavel Stehule <pavel.stehule@gmail.com>
>>
>> Hello
>>
>> I am looking on new feature - ORDER clause in aggregate, and I thing,
>> so we are able to effectively implement some non standard, but well
>> known aggregates.
>>
>> a) function median - it is relative frequent request - with usually
>> slow implementation
>>
>> b) function listagg (it is analogy of group_concat from MySQL) - it
>> should simplify report generating and some other
>>
>> What is your opinion? Do you like to see these functions in core?
>>
>>
>
> I'm probably missing the point here, but when I originally saw MySQL's
> group_concat function, I found it odd that it featured ordering
> functionality.  Shouldn't the order by determined by the query itself?
> Otherwise it's almost as if its separating the relationship between the
> result column and the resultset.
>

Aggregates as group_concat or listagg are not typical SQL aggregates.
With these aggregates we are able to do some reports on SQL level
without stored procedures. What I know, order is determined only for
non hash aggregates - and you cannot specify method of aggregation, so
possibility to specify ORDER is important. But this feature isn't
related to this "proposal". It was commited yesterday - so you can
look on discussion about this feature.

Regards
Pavel Stehuke

> Thom
>
>


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Update on true serializable techniques in MVCC
Next
From: Simon Riggs
Date:
Subject: Re: Fast or immediate shutdown