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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers