Re: JSON path decimal literal syntax

I noticed that the JSON path lexer does not support the decimal literal
syntax forms

.1
1.

(that is, there are no digits before or after the decimal point). This
is allowed by the relevant ECMAScript standard
(https://262.ecma-international.org/5.1/#sec-7.8.3) and of course SQL
allows it as well.

Is there a reason for this? I didn't find any code comments or
documentation about this.

Attached are patches that would enable this. As you can see, a bunch of
test cases are affected.

On 18.02.22 11:17, Peter Eisentraut wrote:
> I noticed that the JSON path lexer does not support the decimal literal
> syntax forms
>
> .1
> 1.
>
> (that is, there are no digits before or after the decimal point).  This
> is allowed by the relevant ECMAScript standard
> (https://262.ecma-international.org/5.1/#sec-7.8.3) and of course SQL
> allows it as well.
>
> Is there a reason for this?  I didn't find any code comments or
> documentation about this.

It has come to my attention that there are syntactic differences between
JavaScript, which is what JSON path is built on, and JSON itself.
Presumably, the JSON path lexer was originally built with the JSON
syntax in mind.

Attached is an updated patch that implements the JavaScript-based JSON
path numeric literal syntax more correctly. Besides the above mentioned
syntax forms, it now also rejects trailing junk after numeric literals
more correctly, similar to how the main SQL lexer does it.

On 24.02.2022 21:24, Peter Eisentraut wrote:

> On 18.02.22 11:17, Peter Eisentraut wrote:
>> I noticed that the JSON path lexer does not support the decimal
>> literal syntax forms
>>
>> .1
>> 1.
>>
>> (that is, there are no digits before or after the decimal point). 
>> This is allowed by the relevant ECMAScript standard
>> (https://262.ecma-international.org/5.1/#sec-7.8.3) and of course SQL
>> allows it as well.
>>
>> Is there a reason for this?  I didn't find any code comments or
>> documentation about this.
>
> It has come to my attention that there are syntactic differences
> between JavaScript, which is what JSON path is built on, and JSON
> itself. Presumably, the JSON path lexer was originally built with the
> JSON syntax in mind.
>
> Attached is an updated patch that implements the JavaScript-based JSON
> path numeric literal syntax more correctly.  Besides the above
> mentioned syntax forms, it now also rejects trailing junk after
> numeric literals more correctly, similar to how the main SQL lexer
> does it.

By the standard, jsonpath borrows its decimal literal syntax from the SQL,
so I think these lexer fixes are necessary.

Obviously, there are compatibility issues with expressions like
'1.type()', which will start to require parentheses around numbers,
but they seem to be useful only for our regression tests.

The corresponding changes in jsonpath_out() related to parentheses
are missing in the v2 patch:

=# select '(1).a'::jsonpath;
jsonpath
----------
1."a"
(1 row)

=# select '(1).a'::jsonpath::text::jsonpath;
ERROR: syntax error, unexpected STRING_P, expecting $end at or near """ of jsonpath input

I have added in v3 enclosing of numbers in parentheses if they have
successive path items. (Changed results of several test cases, one test
case added.)

--
Nikita Glukhov
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company

On 06.03.22 02:43, Nikita Glukhov wrote:
> Obviously, there are compatibility issues with expressions like
> '1.type()', which will start to require parentheses around numbers,
> but they seem to be useful only for our regression tests.
>
> The corresponding changes in jsonpath_out() related to parentheses
> are missing in the v2 patch:
>
> =# select '(1).a'::jsonpath;
> jsonpath
> ----------
> 1."a"
> (1 row)
>
> =# select '(1).a'::jsonpath::text::jsonpath;
> ERROR: syntax error, unexpected STRING_P, expecting $end at or near """ of jsonpath input
>
>
> I have added in v3 enclosing of numbers in parentheses if they have
> successive path items. (Changed results of several test cases, one test
> case added.)

Thank you for these insights. I have integrated this into my patch and
updated the commit message to point out the change.