Implement window function support

We should create derivates of the standard aggregate functions e.g. count -> count_window that support the FILTER and OVER clauses. The FILTER clause will always have to be rendered by using a CASE WHEN statement in the function. The OVER clause should support PARTITION, ORDER BY and ROWS/RANGE clauses and also accept a named window. In order to support a named window, we would first have to add support for adding windows to a query. I propose to add a method to start a window builder on a QueryBuilder e.g. window(String name). There you can define partitions, orderings and framing. Note that windows defined in a subquery have precedence for that subquery. So windows can shadow same named windows from the parent query.

Note that since there is semantically no difference between reusing a window name or inlining the window clause, we will always inline the contents to the window functions as this is easier to implement because it doesn’t require SQL replacements.

Here are some links to documentation about this

• https://msdn.microsoft.com/en-us/library/ms189461.aspx
• https://www.simple-talk.com/sql/t-sql-programming/window-functions-in-sql/
• https://blog.jooq.org/2013/11/03/probably-the-coolest-sql-feature-window-functions/
• http://modern-sql.com/feature/filter

The following functions would be affected by this

• AVG
• MIN
• MAX
• SUM
• EVERY?
• COUNT
• COUNT_STAR
• GROUP_CONCAT

Also see the following reference: https://en.wikibooks.org/wiki/SQL_Dialects_Reference/Functions_and_expressions/Math_functions/Aggregate_functions

While doing that we could also look into adding some window only functions: https://www.postgresql.org/docs/8.4/static/functions-window.html

[jwgmeligmeyling]

Ok! Then we’re on the same page. I’ll keep needing Window functions here and there, so I am considering to have a look at it in the next few days.

[beikov]

IMO, the syntax support for expression in the Blaze-Persistence APIs should be as close to SQL as possible i.e. allow to do criteriaBuilder.select("avg(salary) over (partition by depname order by depname asc)"). The translation to JPQL could be like FUNCTION('AVG', salary, 'OVER', 'PARTITION BY', depname, 'ORDER BY', depname, 'ASC'). The JPQLFunction implementation then renders that to SQL. Let’s ignore uses when the DBMS does not support it for now to avoid having to detect the DBMS versions.