More than two OR-ed expressions in SELECT not properly evaluated

[yvesf]

In the following example the second response is obviously wrong.
It makes no difference if the field named 'type' is a tag or just a field.
If the query is changed to span multiple series, this can lead to errors like #2299 if the value field has different types and a function like mean() is applied.

> SELECT type FROM "my.pretty.series" WHERE type = 'data1c' OR type = 'bit'
name: my.pretty.series
-----------------------------------------------------------
time    type
> SELECT type FROM "my.pretty.series" WHERE type = 'data1c' OR type = 'bit' OR type = 'data1b'
name: my.pretty.series
-----------------------------------------------------------
time                    type
2015-05-10T17:22:25Z    byteEnum
2015-05-10T17:22:28Z    byteEnum
2015-05-10T17:27:27Z    byteEnum
2015-05-10T17:27:35Z    byteEnum
2015-05-10T17:27:55Z    byteEnum
2015-05-10T17:28:05Z    byteEnum
2015-05-10T17:28:25Z    byteEnum

I'm running v0.9.0-rc29 with:
TOML_GH_COMMIT= 056c9bc # github.com/BurntSushi/toml
PAT_GH_COMMIT= b8a3500 # github.com/bmizerany/pat
BOLT_GH_COMMIT= 2c04100 # github.com/boltdb/bolt
GOLLECTD_GH_COMMIT= cf6dec9 # github.com/kimor79/gollectd
LINER_GH_COMMIT= 1bb0d1c # github.com/peterh/liner
STATIK_GH_COMMIT= 274df12 # github.com/rakyll/statik
GOCRYPTO_GH_COMMIT= 24ffb5f # golang.org/x/crypto

with go1.4.2 freebsd/amd64on 10.1-RELEASE. I'm using it from a non-official freebsd-port. To have it reproducible the commit-id's from the dependencies are hardcoded in the recipe. It would be nice if influxdb defines them (maybe along with using godep).

[beckettsean]

For me on RC29 it only happens with fields, not tags.

Using RC29,
SELECT value FROM series WHERE value=1 OR value=2 returns the expected subset of points matching the WHERE clause, but
SELECT value FROM series WHERE value=1 OR value=2 OR value=3 returns every point in the series, regardless of whether the measurement is actually 1, 2, 3, or something else entirely.