Yeah, it seems like adding a flag like iswindowable to aggregate
functions is the safest option.
It would be nice if it represented an abstract property of the state
function or final function rather than just "works with the
implementation of window functions". I'm not sure what that property
is though - isidempotent? isreentrant? Maybe just a vague isrepeatable?
--
Greg
On 24 Dec 2008, at 20:16, "Hitoshi Harada" <umi.tan...@gmail.com> wrote:
2008/12/25 Tom Lane <t...@sss.pgh.pa.us>:
Gregory Stark <st...@enterprisedb.com> writes:
Tom Lane <t...@sss.pgh.pa.us> writes:
Unless we want to move the goalposts on what an aggregate is
allowed
to do internally, we're going to have to change this to re-
aggregate
repeatedly. Neither prospect is appetizing in the least.
Does it currently copy the state datum before calling the final
function?
Would that help?
No. The entire point of what we have now formalized as "aggregates
with
internal-type transition values" is that the transition value isn't
necessarily a single palloc chunk. For stuff like array_agg, the
performance costs of requiring that are enormous.
On looking at what array_agg does, it seems the issue there is that
the final-function actually deletes the working state when it thinks
it's done with it (see construct_md_array). It would probably be
possible to fix things so that it doesn't do that when it's called by
a WindowAgg instead of a regular Agg. What I'm more concerned about
is what third-party code will break. contrib/intagg has done this
type of thing since forever, and I'm sure people have copied that...
I have concerned it once before on the first design of the window
functions. I don't have much idea about all over the aggregate
functions but at least count(*) does some assumption of AggState in
its context. So I concluded when the window functions are introduced
it must be announced that if you use aggregate in the window context,
you must be sure it supports window as well as aggregate. It is
because currently (<= 8.3) aggregates are assumed it is called in
AggState only but the assumption would be broken now. It is designed,
and announcing helps much third party code to support or not to
support window functions (i.e. you can stop by error if window is not
supported by the function).
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
