You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal: Allow most functions in InfluxQL to be nested. Simplify and document the rules about which combinations are valid.
Current behavior: Not many functions allow nesting, so for example this query is forbidden even though it might be useful:
SELECT last(elapsed(value)) FROM ...
It is also not clear from the documentation (or the code!) which combinations are allowed. For example, you are allowed to do this:
SELECT derivative(mean(Alloc)) FROM runtime WHERE time > now() - 1d GROUP BY time(1h)
but not this:
SELECT max(mean(Alloc)) FROM runtime WHERE time > now() - 1d GROUP BY time(1h)
I wrote a new function but found it difficult to integrate with the query language because the nesting rules for each function seem to be individually hand-crafted - there was no way to say "this is another aggregator, just apply the normal aggregator rules and let people use it wherever an aggregator is valid".
Desired behavior: You can nest any functions as deeply as you like, subject to a few rules based on the function categories.
The function categories are already defined in the documentation but are not used much in the code. They already effectively determine the behaviour in many situations (particularly group-by queries), although these rules are not currently explicit in either the code or the documentation.
Use case: There are many cases where nesting functions is useful. Many of the proposed future functions are "single-point operators" like sqrt or sin and users will definitely expect to be allowed to nest these.
Specifying function composition rules in terms of categories rather than on a per-function basis will be a lot more scalable as more functions are added, and will make the behaviour easier to document.
The text was updated successfully, but these errors were encountered:
I think this is likely going to be implemented by subqueries. I think we have an issue for that open somewhere, but I'll have to find it. For math functions (which we have none at the moment, but we do plan to add those at some point) like pow() and sqrt, those will be nestable and they will get treated the same as if they were normal variable references whenever we get around to that. I should make an issue to discuss the implementation of that.
Feature Request
Proposal: Allow most functions in InfluxQL to be nested. Simplify and document the rules about which combinations are valid.
Current behavior: Not many functions allow nesting, so for example this query is forbidden even though it might be useful:
It is also not clear from the documentation (or the code!) which combinations are allowed. For example, you are allowed to do this:
but not this:
I wrote a new function but found it difficult to integrate with the query language because the nesting rules for each function seem to be individually hand-crafted - there was no way to say "this is another aggregator, just apply the normal aggregator rules and let people use it wherever an aggregator is valid".
Desired behavior: You can nest any functions as deeply as you like, subject to a few rules based on the function categories.
The function categories are already defined in the documentation but are not used much in the code. They already effectively determine the behaviour in many situations (particularly group-by queries), although these rules are not currently explicit in either the code or the documentation.
Use case: There are many cases where nesting functions is useful. Many of the proposed future functions are "single-point operators" like sqrt or sin and users will definitely expect to be allowed to nest these.
Specifying function composition rules in terms of categories rather than on a per-function basis will be a lot more scalable as more functions are added, and will make the behaviour easier to document.
The text was updated successfully, but these errors were encountered: