Thread: 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.
Attachment
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.
Attachment
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
Attachment
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.