You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@tloubrieu-jpl what's the intended behaviour, precisely?
If we want to implement parenless operator precedence, that's probably complicated on both implementation and user sides, and not desirable imho.
If the only case this is intended to cover is "If the user writes an invalid query which would be valid if they'd remembered an all-enclosing/outermost set of parens", then I think that's an uncomplicated value-add for the user and it's also trivial to implement (just transform every user-supplied query string with an additional set of parens). These will probably get parsed out if they're redundant, but if not it's still trivial to only transform query strings that aren't enclosed.
💡 Description
Especially, could we make it accept q query without surrounding brackets, e.g. for query:
We would also accept:
See ticket NASA-PDS/pds-api#259
The text was updated successfully, but these errors were encountered: