Now we have switched to using function extensions for regexp filter matches, the current syntax requires the result to be compared against a boolean, as shown in this example from PR 330:
$[?match(@.timezone, 'Europe/.*') == true]
This is consistent with the following statement in the "Existence Tests" section of the spec:
To test the value of a node selected by a path, an explicit comparison is necessary.
If we wanted the following syntax to act as a regexp test:
$[?match(@.timezone, 'Europe/.*')]
we would have to allow a function expression (returning a boolean result) to be treated as a relation-expr (rather than an exist-expr or a comparable). This would require (a) considerable rework of filter selectors and (b) making a special case of functions which return booleans. To be clear: I am not in favour of such a change.
The reason for raising this issue was so that it doesn't come as a surprise to the WG. Thanks to @cabo who spotted it when reviewing some draft input to PR 330.
glyn
commented
1 year ago
Now we have switched to using function extensions for regexp filter matches, the current syntax requires the result to be compared against a boolean, as shown in this example from PR 330:
This is consistent with the following statement in the "Existence Tests" section of the spec:
If we wanted the following syntax to act as a regexp test:
we would have to allow a function expression (returning a boolean result) to be treated as a
relation-expr(rather than anexist-expror acomparable). This would require (a) considerable rework of filter selectors and (b) making a special case of functions which return booleans. To be clear: I am not in favour of such a change.The reason for raising this issue was so that it doesn't come as a surprise to the WG. Thanks to @cabo who spotted it when reviewing some draft input to PR 330.