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
