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
insome 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
shouldthat be parsed? As an invalid decimal expression ("trailing junk after numeric literal”), or as a valid integer 2
followedby 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
decimalexpression. 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.
