Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> The window functions patch is laboring under the delusion that it can
> call an aggregate's final function and then go back to invoking the
> transfn some more on the same data. This is merest fantasy :-(
> regression=# select array_agg(q1) over(order by q1) from int8_tbl;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> 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?
It does seem like the abstract interface we have for aggregate functions is a
strength and we should leverage that. The burden of supporting more complex
cases should be borne by the users that are bending the rules.
Ask me about EnterpriseDB's PostGIS support!
In response to
pgsql-hackers by date
|Next:||From: Robert Treat||Date: 2008-12-24 04:59:19|
|Subject: Re: Hot standby and b-tree killed items|
|Previous:||From: Tom Lane||Date: 2008-12-24 03:20:45|
|Subject: Window-functions patch handling of aggregates|