Re: ❓ JSON Path Dot Precedence

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.