On 07.04.24 18:13, David E. Wheeler wrote:
Hello Hackers,
A question about the behavior of the JSON Path parser. The docs[1] have this to
say about numbers:
Numeric literals in SQL/JSON path expressions follow JavaScript rules, which
are different from both SQL and JSON in some minor details. For example,
SQL/JSON path allows .1 and 1., which are invalid in JSON.
In other words, this is valid:
david=# select '2.'::jsonpath;
jsonpath
----------
2
But this feature creates a bit of a conflict with the use of a dot for path
expressions. Consider `0x2.p10`. How should that be parsed? As an invalid decimal
expression ("trailing junk after numeric literal”), or as a valid integer 2
followed by the path segment “p10”? Here’s the parser’s answer:
david=# select '0x2.p10'::jsonpath;
jsonpath
-----------
(2)."p10"
So it would seem that, other things being equal, a path key expression (`.foo`)
is slightly higher precedence than a decimal expression. Is that
intentional/correct?
I think the derivation would be like this:
(I'm not sure what the top-level element would be, so let's start
somewhere in the middle ...)
<JSON unary expression> ::= <JSON accessor expression>
<JSON accessor expression> ::= <JSON path primary> <JSON accessor op>
<JSON path primary> ::= <JSON path literal>
<JSON accessor op> ::= <JSON member accessor>
<JSON member accessor> ::= <period> <JSON path key name>
So the whole thing is
<JSON path literal> <period> <JSON path key name>
The syntax of <JSON path literal> and <JSON path key name> is then
punted to ECMAScript 5.1.
0x2 is a HexIntegerLiteral. (There can be no dots in that.)
p10 is an Identifier.
So I think this is all correct.
