[feature request] allow WHERE clause binary expressions on non-column values #3558
Comments
beckettsean
changed the title
|
@joshuawarner32 I can't say how challenging it would be, but PRs are always welcome. @dgnorton or @otoolep any thoughts on whether this is a reasonable thing for a community PR? |
|
The specific problem with this is that @joshuawarner32 must want to perform division on tags. But tags are always stored as strings. Performing math is not possible. |
|
I might be mistaken actually, I guess |
|
If the references in the |
|
@otoolep - yes,
Hmm. That doesn't sound promising. I may still take a stab at it, depending on what else I find on my plate. |
|
I think this should currently be possible and the error is probably validation being too strict. I'm going to try it for a bit. Throwing this into the 0.13 milestone temporarily. If it turns out to be more difficult than I originally expected, we may have to push it back, but I think it should be easily feasible with the new query engine. |
Binary math inside of a where condition was previously disallowed. Now,
these types of queries are just passed verbatim down to the underlying
query engine which can handle it.
We may want to revisit this when it comes to tags at some point as it
prevents the more efficient filtering of tags that a simple expression
allows, but it allows a query like this to be done:
SELECT * FROM cpu WHERE value + 2 < 5
So while it can be better, this is a good initial implementation to
provide this functionality. There are very rare situations where a tag
may be used appropriately in one of these circumstances.
Fixes #3558.
Binary math inside of a where condition was previously disallowed. Now,
these types of queries are just passed verbatim down to the underlying
query engine which can handle it.
We may want to revisit this when it comes to tags at some point as it
prevents the more efficient filtering of tags that a simple expression
allows, but it allows a query like this to be done:
SELECT * FROM cpu WHERE value + 2 < 5
So while it can be better, this is a good initial implementation to
provide this functionality. There are very rare situations where a tag
may be used appropriately in one of these circumstances.
Fixes #3558.
Binary math inside of a where condition was previously disallowed. Now,
these types of queries are just passed verbatim down to the underlying
query engine which can handle it.
We may want to revisit this when it comes to tags at some point as it
prevents the more efficient filtering of tags that a simple expression
allows, but it allows a query like this to be done:
SELECT * FROM cpu WHERE value + 2 < 5
So while it can be better, this is a good initial implementation to
provide this functionality. There are very rare situations where a tag
may be used appropriately in one of these circumstances.
Fixes #3558.
Binary math inside of a where condition was previously disallowed. Now,
these types of queries are just passed verbatim down to the underlying
query engine which can handle it.
We may want to revisit this when it comes to tags at some point as it
prevents the more efficient filtering of tags that a simple expression
allows, but it allows a query like this to be done:
SELECT * FROM cpu WHERE value + 2 < 5
So while it can be better, this is a good initial implementation to
provide this functionality. There are very rare situations where a tag
may be used appropriately in one of these circumstances.
Fixes #3558.
I've been trying to do various queries of the form
SELECT * FROM the_series WHERE column1 / column2 > 0.5. Influxdb consistently gives me an "invalid expression" error. The particulars of the table and column layout aren't important; this happens everywhere I've tried queries of that form.In fact, it happens for every
WHEREclause expression in the form of a binary expression where neither side is itself a column reference. Digging around in the code, I can see this is the likely culprit: https://github.com/influxdb/influxdb/blob/master/tsdb/meta.go#L633My questions are these: Is there a plan to remove that restriction? Would it be difficult? Would a PR be accepted? Where do I start?
Thanks.
The text was updated successfully, but these errors were encountered: