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