The HAVING clause, as in SQL, has been originally introduced to restrict a query according to value returned by an aggregat function, e.g.:
Any X GROUPBY X WHERE X relation Y HAVING COUNT(Y) > 10
It may however be used for something else...
For instance, let's say you want to get people whose uppercased first name equals to another person uppercased first name. Since in the WHERE clause, we are limited to 3-expression (<subject> <relation> <object>), such thing can't be expressed (believe me or try it out). But this can be expressed using HAVING comparison expression:
Person X WHERE X firstname XFN, Y firstname YFN HAVING X > Y, UPPER(XFN) = UPPER(YFN)
Nice, no? This open some new possibilities. Another example:
Person X WHERE X birthday XB HAVING YEAR(XB) = 2000
Get it? That lets you use transformation functions not only in selection but for restriction as well, which was the major flaw in the RQL language.
Notice that while we would like this to work without the HAVING clause, this can't be currently be done because it introduces an ambiguity in RQL's grammar that can't be handled by yapps, the parser's generator we're using.
- cubicweb #246942 supporting aggregates in SET queries
- cubicweb #1947456 ORM should not try to re-fetch initiator relation/entity
- cubicweb #1697862 ORDERBY SUM(C) seems to cancel GROUPBY
- cubicweb #509109 transitivity of relationships
- cubicweb #1381497 support substitution of list of elements passed to RQL IN predicate