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.
- TheCubicWebBook #1231143 [rql] add documentation for group_concat usage
- cubicweb #1356884 ms: tb on rql generated by the no_relation feature of RelationFacet
- cubicweb #1079123 Have a fetch_attr like feature for RQL requests
- cubicweb #1922945 conditional log of rql queries
- cubicweb #615294 reuse rql built through the use of facets