Josh Berkus wrote:
> Hah, I didn't realize that our ordered aggregate syntax even *was* spec.
The spec defines agg(x order by y) only for array_agg and xmlagg; the
generalization to arbitrary other aggregates is our extension. (But
kind of obvious really.)
> > Our implementation does heavily reuse the existing executor mechanics
> > for ORDER BY in aggregates, and it also reuses a fair chunk of the
> > parser code for it, but there are significant differences.
>
> Well, seems like it would work the same as
>
> agg_func(constx,coly,colz ORDER BY coly, colz)
>
> ... which means you could reuse a LOT of the internal plumbing. Or am I
> missing something?
You missed the part above which said "...does heavily reuse..." :-)
i.e. we are in fact reusing a lot of the internal plumbing.
> Also, what would a CREATE AGGREGATE and state function definition for
> custom WITHIN GROUP aggregates look like?
Now this is exactly the part we haven't nailed down yet and want ideas
for.
The problem is, given that the parser is looking at:
foo(p1,p2,...) within group (order by q1,q2,...)
how do we best represent the possible matching functions in pg_proc
and pg_aggregate? Our partial solution so far does not allow
polymorphism to work properly, so we need a better way; I'm hoping for
some independent suggestions before I post my own ideas.
--
Andrew (irc:RhodiumToad)