Incorrect parsing of regex containing '/'

[dawbs]

Running official nightly from 0.9.2 downloaded 22 Jul 2015

when using a regex where clause, a regex containing the '/' character will be truncated even if it is properly escaped. This is problematic when you have used a URL as a tag

(likely any clause after having a bit of a look at the code)

The following query fails:

SELECT * from measurement WHERE url =~ /http\:\/\/www.akamai\.com/

Escaping the escaping backslash as below appears to get around the problem, but is then not a valid go regex anymore

SELECT * from measurement WHERE url =~ /http\:\\/\\/www.akamai\.com/

[dawbs]

Test case:
create database

curl -G http://localhost:8086/query --data-urlencode "q=CREATE DATABASE mydb"

write data

curl -d 'test,url=http://www.akamai.com value=404' http://localhost:8086/write?db=mydb
curl -d 'test,url=https://influxdb.com value=418' http://localhost:8086/write?db=mydb

Query using Go regex - Does not produce expected output:

curl -G http://localhost:8086/query  --data-urlencode 'db=mydb' --data-urlencode 'q=SELECT * FROM test WHERE url =~ /http\:\/\/www.akamai\.com/'

Query using double escaped regex - does produce expected output:

curl -G http://localhost:8086/query  --data-urlencode 'db=mydb' --data-urlencode 'q=SELECT * FROM test WHERE url =~ /http\:\\/\\/www.akamai\.com/'

I have written some failing go tests and am having a bit of a look, but still getting my head around the project

[dawbs]

And further, the edge case seems to be two // characters

Either one of the following two queries DO produce the correct output:

SELECT * FROM test WHERE url =~ /http\:\\/\/www.akamai\.com/
SELECT * FROM test WHERE url =~ /http\:\/\\/www.akamai\.com/

[beckettsean]

Thanks for the excellent bug characterization, @dawbs.

@dgnorton is this a quick fix, you think?

[dawbs]

Sorry for the horrible git fail there . . .

There is fix in the open pull request and a couple of tests. Would love another few eyes more familiar with the project to have a look over.

[jsternberg]

It looks like a PR was merged for this bug for 0.9.5. I'm going to close out this issue. If this is still an issue, please reopen this ticket.