Hello I am thinking about implementation of median function. This function should be implemented in two ways:
a) direct entering an ORDER BY clause for median funcall in gram.y b) general support for "preordered aggregates". I prefer plan b, because there are more similar aggregates - like Quantiles. So with general support of preordered aggregates we can move these aggregates to contrib, separate library or core (if we would). I am for median in core - and others in contrib - as example of this kind of aggregates. What we need: a) some new intelligence in parser - it use default ORDER BY clause when explicit ORDER BY clause is missing. b) for effective implementation we need to know real number of tuples in state function. Without this knowledge we have to copy tuples to tuple store or to array. It is useless, because we have to execute sortby before - so we have this information. There could be one optimalisation. We don't need to process all rows - for median we have to process only 1/2 of rows - it could be nice, if state function can send signal - don't call me more. New syntax: CREATE AGGREGATE name ( input_data_type [ORDER BY [(DESC|ASC)]] [ , ... ] ) ( SFUNC = sfunc, STYPE = state_data_type [ , FINALFUNC = ffunc ] [ , INITCOND = initial_condition ] [ , SORTOP = sort_operator ] ) example: CREATE AGGREGATE median (float8 ORDER BY) ( SFUNC = median_state, STYPE = internal, FINALFUNC = median_final, SORTOP = '<' ) I would to insure, so this idea is acceptable. Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers