**Correl:** Scott0_: For some operators order matters for god sake

**Uvalle:** In relation to each other is an order

**Correl:** Scott0_: WHERE x y is not the same as WHERE y x

**Ryu:** So precedence is an order

**Correl:** Scott0_: Not at all. Precedence is NOT an order

**Nogales:** That’s an operator inside of a condition

**Correl:** Scott0_: AND is operator too

**Merriman:** I was speaking about the order that the conditions were written in, but was told there is no such thing an order of conditions even though theyc an be written in an order

**Keiter:** Scott0_: when you mix the AND and OR operators, precedence matters.

**Correl:** Keiter: When you mix other operators too, but I know you know it

**Lanterman:** Salle: I’ve always looked at AND and OR as a different level of operator than = and

**Keiter:** Scott0_: WHERE a OR b AND c AND d is the same as WHERE a OR d AND b AND c

**Correl:** Scott0_: They have different precedence not different level

**Jarosh:** Keiter: precedence is a type of order.

**Lamery:** Precedence: the condition of being considered more important than someone or something else; priority in importance, order, or rank.

**Carrazco:** Trying to create a stored procedure, so i can run something with different arguments many times – i’m not sure about how to correctly p*** in arguments – is this on the right track? http://pastebin.com/QHMiq4M4

**Keiter:** Scott0_: no. Grouping.

**Ingersoll:** So the english language and deifnitions have no place here?

**Keiter:** Scott0_: each grouped expression is evaluated against another.

**Keiter:** Scott0_: think back to Math cl*** in high school – WHERE a OR b OR c

**Veater:** Keiter: are you talking about nested conditions?

**Correl:** Aeiou: There is no point in wrapping single SELECT into procedure. Not in MySQL at least

**Keiter:** Scott0_: first, a is compared to b. Then, the result of that comparison is compared to c.

**Keiter:** Scott0_: brackets are a means to enforce a certain operator precedence

**Koza:** And I would say that’s an order of operations

**Huotari:** I just wanted to be able to do something like show_references_without_fk‘attribute_id’, ‘eav_attribute’

**Keiter:** Scott0_: it isn’t. It’s grouping.

**Bidrowski:** Salle: just a simplistic helper that’s all – do you see what i mean?

**Correl:** Aeiou: There is no point in wrapping single SELECT into procedure

**Keiter:** Scott0_: naturally, humans will attempt to evaluate it from left to right. But there’s no guarantee that the computer will do the same.

**Mcmurray:** Keiter: then what is a=1 AND b=2 OR c=3 AND d=4?

**Serb:** Salle: what about if the point is reduce typing?

**Checketts:** Keiter: understood on the left to right, which way does mysql handle it?

**Correl:** Scott0_: Any way it deems efficient

**Keiter:** Scott0_: grouping two expressions, to ensure a specific precedence.

**Quispe:** Salle: is there an alternative way to achieve less typing, but with the same result without a stored procedure

**Keiter:** Scott0_: MySQL may decide to evaluate c=3 AND d=4 first, or not.

**Keiter:** Scott0_: in the end, it doesn’t matter.

**Correl:** Scott0_: It does not matter if you write this as: a=1 AND b=2 OR c=3 AND d=4; d=4 AND c=3 OR a=1 AND b=2; b=2 AND a=1 OR c=3 AND d=4 etc.

**Lafontant:** So throw your conditions at the query, and then figure out how to optimize by index

**Colaizzi:** Because you’ll never know how it will evaluate the conditions until you use the explain

**Correl:** Scott0_: Once the query is p****d by the p****r these will trigger exactly the same piece of code

**Gaubert:** How can the engine be so unpredictable?

**Keiter:** Scott0_: it’s not unpredictable, really.