Influxdb: Inequalities in the SELECT clause should return a parse error

[desa]

Using any of =,!=,<,>,<=,>= will yield empty results for all types.

[pauldix]

Can you give an example query?

[desa]

Sorry I forgot to provide one.

> select value < 10 from cpu limit 10
name: cpu
---------
time                value
2015-07-31T20:50:08.547409693Z
2015-07-31T20:50:08.547413908Z
2015-07-31T20:50:08.547415158Z
2015-07-31T20:50:08.547415841Z
2015-07-31T20:50:08.547416493Z
2015-07-31T20:50:08.547417069Z
2015-07-31T20:50:08.547417675Z
2015-07-31T20:50:08.547418243Z
2015-07-31T20:50:08.547544166Z
2015-07-31T20:50:08.547544742Z

[pauldix]

ok, this should actually be a different bug. That query is invalid. Inequalities are only valid in the WHERE clause of a query.

What you should get if you enter a query like that is an error. Updating the title of the bug

[desa]

Some what related:

select value AND value from cpu

causes panic

panic: interface conversion: interface is float64, not map[string]interface {}

goroutine 52 [running]:
github.com/influxdb/influxdb/tsdb.(*limitedRowWriter).processValues(0xc208042000, 0xc208176000, 0x2710, 0x2710, 0x0)
    /Users/michaeldesa/go/src/github.com/influxdb/influxdb/tsdb/executor.go:689 +0xc63
github.com/influxdb/influxdb/tsdb.(*limitedRowWriter).Add(0xc208042000, 0xc20815e000, 0x2710, 0x3000, 0xd26bd0)
    /Users/michaeldesa/go/src/github.com/influxdb/influxdb/tsdb/executor.go:587 +0x370
github.com/influxdb/influxdb/tsdb.(*Executor).executeRaw(0xc20827c210, 0xc208252120)
    /Users/michaeldesa/go/src/github.com/influxdb/influxdb/tsdb/executor.go:285 +0x951
created by github.com/influxdb/influxdb/tsdb.(*Executor).Execute
    /Users/michaeldesa/go/src/github.com/influxdb/influxdb/tsdb/executor.go:82 +0x89

[RobMcZag]

I think that something like

SELECT (TEMP < 25) FROM daily_temp

should be a possible ( and useful) query, quite different from

SELECT TEMP FROM daily_temp WHERE TEMP < 25

The first will tell me, for every time bucket I can group on, if some condition is met or not, while the latter will return me only values (and timestamps) when it was met or not.

[beckettsean]

@RobMcZag I don't understand the difference. A query like SELECT * FROM daily_temp WHERE temp < 25 GROUP BY time(1d) will give you the answers you attribute to the SELECT (temp < 25)... query.

If you disagree, please open a new GitHub Issue describing your use case, and demonstrating how existing queries are insufficient.

[RobMcZag]

@beckettsean sorry to reply so late, Just got now the notification.

The first query will return, for every interval, if the predicate is true or false;
the second will return the field(s) you ask for only for one of the two cases you select: if it is true or false.

I think the two are quite different, as the first will give you the desired value on a completely filled time dimension, while the second will usually return a fragmented time dimension.

The first is much easier to use to graph the result or to take different action for every interval (you already have all of them and you can just iterate through).

Do you agree they are quite different results?

If you think appropriate I can open an issue for a new feature request, as for what I understand, now we are not supposed to use expressions (or even simple inequalities) outside the where clause. Am I right here?

[beckettsean]

Do you agree they are quite different results?

I understand the difference now. The SELECT (TEMP < 25) FROM daily_temp query doesn't return the points, just a boolean for the time range. That is definitely new functionality and not something that can be done now in a single query, as far as I can see.

If you think appropriate I can open an issue for a new feature request, as for what I understand, now we are not supposed to use expressions (or even simple inequalities) outside the where clause. Am I right here?

Please do open a new feature request for this. Comparisons and other operators are currently invalid outside the WHERE clause.

[claybar]

Did this ever get raised as a feature request? Case #3552 seems close, but not quite the same thing.