From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Idea for aggregates |
Date: | 2014-04-14 16:43:19 |
Message-ID: | CA+U5nMKSFhzM5G+XyYpQV33kyD29z+GPH1yMYRG-SqHSGzHjuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5 April 2014 04:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)mit(dot)edu> writes:
>> Well in many cases stype will just be internal for many of them. That
>> doesn't mean they're the same.
>
>> Hm, I suppose it might if they have the same sfunc.
>
>> This is actually where I started but we concluded that we needed some
>> declaration that the aggregates were actually related and would interpret
>> the state the same way and not just that it happened to use the same
>> storage format.
>
> Well, in practice you'd need to also compare the input datatype (consider
> polymorphic aggregates) and initcond. But the sfunc isn't told which
> finalfunc will be applied, so any aggregates that share the same sfunc and
> have the other conditions the same *must* have the identical transition
> data behavior. I don't see any reason to invent new syntax, and there
> are good reasons not to if we don't have to.
Definitely happy not to have additional syntax. So we can just
dynamically group the aggregates together.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-04-14 16:48:48 | Re: Minor improvements in create_foreign_table.sgml |
Previous Message | Robert Haas | 2014-04-14 16:43:08 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |