On Thu, Jul 18, 2013 at 10:33:15PM +0000, Andrew Gierth wrote:
> Josh Berkus wrote:
> > Well, seems like it would work the same as
> >
> > agg_func(constx,coly,colz ORDER BY coly, colz)
I'd try transforming WITHIN GROUP into the above during parse analysis. The
default would be the transformation for hypothetical set functions:
agg(x,y,z) WITHIN GROUP (ORDER BY a,b,c) -> agg(x,y,z ORDER BY a,b,c)
Add a CREATE AGGREGATE option, say SQL_INVERSE_DISTRIBUTION_FUNCTION =
{true|false} or SQLIDF, that chooses the IDF transformation:
agg(x) WITHIN GROUP (ORDER BY y) -> agg(x, y ORDER BY y)
Then there's perhaps no new core aggregation or function candidacy machinery.
(I don't know whether VARIADIC transition functions work today, but that would
become an orthogonal project.) Compare how we handle standard interval typmod
syntax; only the parser and deparser know about it.
Atri's description upthread sounded pretty similar to that.
> > 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.
PERCENTILE_DISC would be declared as (float8, anyelement) with that SQLIDF
option. To diagnose nonsensical calls made through nonstandard syntax, it
could dig into its AggState to verify that its second argument is equal() to
its first ORDER BY expression.
There would be a question of whether to accept the WITHIN GROUP syntax for any
aggregate or just for those for which the standard indicates it. Then follows
the question of when to deparse as WITHIN GROUP and when to deparse as the
internal syntax. I'd lean toward accepting WITHIN GROUP for any aggregate but
deparsing that way only SQLIDF aggregates and aggregates with names matching
the standard hypothetical set function names. Or you could add a second
CREATE AGGREGATE option requesting hypothetical-set-function deparse style.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com