Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAND operator precedence is too high #555
Comments
This comment has been minimized.
This comment has been minimized.
|
Thanks for reporting! I agree, this should be changed. |
This comment has been minimized.
This comment has been minimized.
|
+1. This bit me today. At the very least the current precedence should be documented. |
This comment has been minimized.
This comment has been minimized.
|
This will be fixed along with the parser / query engine refactoring that is likely to be done in the next couple of weeks. |
This comment has been minimized.
This comment has been minimized.
|
Just merged the new query engine + parser feature branch into master: #676 This should be fixed now. |
juliusv
closed this
May 7, 2015
simonpasquier
pushed a commit
to simonpasquier/prometheus
that referenced
this issue
Oct 12, 2017
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 24, 2019
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
lock
bot
locked and limited conversation to collaborators
Mar 24, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
aecolley commentedFeb 24, 2015
The expression:
time() - start_time{job="x"} > 86400andstart_time{job="x"} > end_time{job="x"}should be parsed as:
(time() - start_time{job="x"} > 86400)and(start_time{job="x"} > end_time{job="x"})but it is actually parsed as:
((time() - start_time{job="x"} > 86400)andstart_time{job="x"}) > end_time{job="x"}rules/lexer.l classifies
ANDandORas CMP_OP just like==and>. They should be a different level of operation.