The JsonPath language isn't standardized. When SQL accommodated it, they actually formally specified the language, however in a different flavor. Example differences:
- array ranges are indexed as
$[1 to 2] instead of $[1:2]
- properties are quoted as
$."property with space" instead of $['property with space']
- separate strict and lax modes: in strict mode, non-existent property or out-of-bounds array index throw, in lax mode they return null.
I'm not deeply familiar with the SQL's nuances, there might be a couple more differences. We're implementing JsonPath support in an SQL engine. My question is have you ever considered supporting the SQL flavor? Would you accept PRs adding support for them, provided that the old syntax is unaffected and the SQL way will be an alternative syntax? So far this seems possible. Or to provide a configuration setting to pick the flavor?
The JsonPath language isn't standardized. When SQL accommodated it, they actually formally specified the language, however in a different flavor. Example differences:
$[1 to 2]instead of$[1:2]$."property with space"instead of$['property with space']I'm not deeply familiar with the SQL's nuances, there might be a couple more differences. We're implementing JsonPath support in an SQL engine. My question is have you ever considered supporting the SQL flavor? Would you accept PRs adding support for them, provided that the old syntax is unaffected and the SQL way will be an alternative syntax? So far this seems possible. Or to provide a configuration setting to pick the flavor?