`<` and `>` cannot be escaped in query strings

[jpountz]

The query_string query has < and > operators that make it easy to build range queries. For instance, age:>18 is equivalent to age:{18 TO *]. The issue however is that given that it is implemented on top of the base Lucene query parser (< and > are handled in MapperQueryParser#getFieldQuerySingle), they cannot be escaped like other query operators. So if you want to search for a term that starts with < or > in a keyword field, the only way to do so is to quote the searched term, eg. my_field:">value".

[jpountz]

I am not sure how we can fix it. One way would be to only support this special notation on numeric fields. For keyword fields, it would always be ambiguous whether these characters are a range operator or part of the keyword? Another way would be to make escaping work like for other special characters but that looks much harder at first sight.

[mrec]

I appreciate that the fix is tricky, but would it be possible to at least update the documentation to make it clear that these characters currently can't be escaped?

I lost a lot of time and hair to headscratching when I first ran into this as an Elastic newbie in 2015, and I've just run into it again today. Accurate docs would have saved a lot of that.

[nik9000]

I appreciate that the fix is tricky, but would it be possible to at least update the documentation to make it clear that these characters currently can't be escaped?

Yes. I'll do that now. I hit the same problem many years ago as well. I remember writing a very perplexed comment about it.

[nik9000]

I added a note to the docs. Hopefully this will help some. The docs should be updated in about 30 minutes.

[mrec]

@nik9000 - thanks!

BTW, the downsides of the quoting workaround @jpountz mentions are:

1. Where the term gets analyzed to multiple tokens it imposes a phrase ordering the caller didn't ask for, and
2. It disables any other special features (e.g. wildcards etc) in the term

If you're only using standard-ish analyzers (i.e. < and > are always nontoken chars) and you know you never want the range interpretation, manually trimming off any leading culprit from the term might be a safer bet. I hadn't realized before that this bug only hits you when it's the first character.

[talevy]

We prefer to close this issue as a clear indication that we do not foresee further developments in the near-term around this. Looks like the documentation was updated to make things clearer. despite this issue being closed please feel free to leave feedback on the proposal (including +1s).