Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inequalities in the SELECT clause should return a parse error #3525

Closed
desa opened this issue Jul 31, 2015 · 9 comments

Comments

Projects
None yet
7 participants
@desa
Copy link
Member

commented Jul 31, 2015

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

@beckettsean beckettsean added this to the 0.9.3 milestone Jul 31, 2015

@beckettsean beckettsean changed the title [feature request] Support for inequalities [0.9.2] (regression) Support for inequalities Jul 31, 2015

@pauldix

This comment has been minimized.

Copy link
Member

commented Aug 3, 2015

Can you give an example query?

@desa

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2015

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

This comment has been minimized.

Copy link
Member

commented Aug 3, 2015

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

@pauldix pauldix changed the title [0.9.2] (regression) Support for inequalities Inequalities in the SELECT clause should return errors Aug 3, 2015

@pauldix pauldix changed the title Inequalities in the SELECT clause should return errors Inequalities in the SELECT clause should return a parse error Aug 3, 2015

@DanielMorsing DanielMorsing self-assigned this Aug 3, 2015

@desa

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2015

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

@levicook levicook added the 2 - Working label Aug 3, 2015

DanielMorsing added a commit to DanielMorsing/influxdb that referenced this issue Aug 4, 2015

check if fields are valid during parse.
Binary expressions that yield a boolean are invalid and we can catch
these at parse time.

Fixes influxdata#3525

@pauldix pauldix closed this in #3541 Aug 4, 2015

@pauldix pauldix removed the 2 - Working label Aug 4, 2015

@RobMcZag

This comment has been minimized.

Copy link

commented Sep 8, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2015

@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

This comment has been minimized.

Copy link

commented Oct 5, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2015

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

This comment has been minimized.

Copy link

commented Oct 15, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.