On Wed, Oct 13, 2010 at 6:56 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2010/10/13 Pavel Stehule <pavel.stehule@gmail.com>:
>> 2010/10/13 Peter Eisentraut <peter_e@gmx.net>:
>>> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
>>>> The problem is in interface. The original patch did it, but I removed
>>>> it. We cannot to unsure immutability of some parameters now.
>>>
>>> How about you store the "immutable" parameter in the transition state
>>> and error out if it changes between calls?
>>>
>>
>> yes, it's possibility. Now I looking there and I see the as more
>> important problem the conformance with ANSI SQL. see my last post.
>> There can be a kind of aggregate functions based on tuplesort.
>
> more - all these functions needs to solve same problem with planner
> and hash agg. So maybe is time to add a flag ISTUPLESORTED to pg_proc
> and add solve these functions together.
I think that the design of this patch is still sufficiently up in the
air that it is not going to be practical to get it committed during
the current CommitFest, which is nearly over, so I am going to mark it
as Returned with Feedback. I suggest that we continue discussing it,
however, so that we can get things squared away for the next
CommitFest. It seems that the fundamental question here is whether
median is an instance of some more general problem, or whether it's a
special case; and more importantly, if it is an instance of a more
general problem, what is the shape of that general problem?
Or to put it more bluntly - what is the "problem with planner and hash
agg" that all of these functions need to solve? And why does it need
a flag in pg_proc? Why can't't we leave it to the individual
functions to perform a sort of one is needed?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company