The evaluation function searchmatch() has just one parameter in the grammar, an EvalStatement. Having it as evalStatement allows for using integerType, fieldType and so on as a parameter, even though it should just support double quoted search strings.
It also supports using other evaluation functions as parameter, like:
%dpl
index=abc | eval a = if(searchmatch(avg(offset, 2)), "true", "false")
Expected behavior
Should only support a double quoted string. Don't just use the EvalStringType: the grammar rules should be completely reworked so that the different comparison operators are introduced in their own grammar rules, and not just in a single string rule. Currently the string is parsed in PTH-10, even though that would be a parser responsibility.
Using "foo" + "bar" should still be supported. Meaning, that it should support eval statements, as long as the return type is a string.
Describe the bug
The evaluation function searchmatch() has just one parameter in the grammar, an EvalStatement. Having it as evalStatement allows for using integerType, fieldType and so on as a parameter, even though it should just support double quoted search strings.
It also supports using other evaluation functions as parameter, like:
Expected behavior
Should only support a double quoted string. Don't just use the EvalStringType: the grammar rules should be completely reworked so that the different comparison operators are introduced in their own grammar rules, and not just in a single string rule. Currently the string is parsed in PTH-10, even though that would be a parser responsibility.
Using "foo" + "bar" should still be supported. Meaning, that it should support eval statements, as long as the return type is a string.
How to reproduce
Run a similar query to the one above.
Screenshots
Software version
pth_10 version: 5.5.0-2-g5f9746ea pth_03 version: 6.1.4
Desktop (please complete the following information if relevant):
Additional context