Re: Window functions patch v04 for the September commit fest

Simon Riggs wrote:
> On Tue, 2008-09-02 at 15:51 +0300, Heikki Linnakangas wrote:
> 
>> The needs of access to the rows are so different that it seems best to
>> me to delegate the buffering to the window function.
> 
> That seems sensible in some ways, not others.

In the API I proposed later in that mail, the buffering is actually done 
by the executor node, not by the window function. Instead, the window 
function can request abitrary rows of the frame from the executor, and 
can signal that some rows are no longer required, allowing them to be 
discarded.

> Some of the window functions, like lead and lag merely specify window
> size and shape for other functions to act upon.

I don't  understand that. LEAD/LAG return a value. They don't affect the 
size or shape of the window in any way. It doesn't affect other functions.

> For those types of
> request I don't see any need for custom functions, whereas for the
> comparison/calculation functions there might be a need.
> 
> We don't need to implement all the things the SQL Standard calls window
> functions with a 1:1 mapping to Postgres functions.

Sure, we have special hacks for things like MIN/MAX already. But using 
PostgreSQL functions does seem like the simplest solution to me, as the 
backend code can get quite complex if we have to add special handling 
for different window functions. LEAD/LAG fall quite nicely into the 
framework I proposed, but if something comes along that doesn't, then 
we'll have to extend the framework or add a special case.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com