Thread: SQL JSON path enhanced numeric literals

Attached is a patch to add nondecimal integer literals and underscores 
in numeric literals to the SQL JSON path language.  This matches the 
recent additions to the core SQL syntax.  It follows ECMAScript in 
combination with the current SQL draft.

Internally, all the numeric literal parsing of jsonpath goes through 
numeric_in, which already supports all this, so this patch is just a bit 
of lexer work and some tests.

On 2/27/23 20:13, Peter Eisentraut wrote:
> Attached is a patch to add nondecimal integer literals and underscores 
> in numeric literals to the SQL JSON path language.  This matches the 
> recent additions to the core SQL syntax.  It follows ECMAScript in 
> combination with the current SQL draft.
> 
> Internally, all the numeric literal parsing of jsonpath goes through 
> numeric_in, which already supports all this, so this patch is just a bit 
> of lexer work and some tests.

Is T840 really NO after this patch?
-- 
Vik Fearing

On 28.02.23 01:09, Vik Fearing wrote:
> On 2/27/23 20:13, Peter Eisentraut wrote:
>> Attached is a patch to add nondecimal integer literals and underscores 
>> in numeric literals to the SQL JSON path language.  This matches the 
>> recent additions to the core SQL syntax.  It follows ECMAScript in 
>> combination with the current SQL draft.
>>
>> Internally, all the numeric literal parsing of jsonpath goes through 
>> numeric_in, which already supports all this, so this patch is just a 
>> bit of lexer work and some tests.
> 
> Is T840 really NO after this patch?

That was meant to be a YES.

On Tue, 28 Feb 2023 at 07:44, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> Attached is a patch to add nondecimal integer literals and underscores
> in numeric literals to the SQL JSON path language.  This matches the
> recent additions to the core SQL syntax.  It follows ECMAScript in
> combination with the current SQL draft.
>

I think this new feature ought to be mentioned in the docs somewhere.
Perhaps a sentence or two in the note below table 9.49 would suffice,
since it looks like that's where jsonpath numbers are mentioned for
the first time.

In jsonpath_scan.l, I think the hex/oct/bininteger cases could do with
a comment, such as

/* Non-decimal integers in ECMAScript; must not have underscore after radix */
hexinteger    0[xX]{hexdigit}(_?{hexdigit})*
octinteger    0[oO]{octdigit}(_?{octdigit})*
bininteger    0[bB]{bindigit}(_?{bindigit})*

since that's different from the main lexer's syntax.

Perhaps it's worth mentioning that difference in the docs.

Otherwise, this looks good to me.

Regards,
Dean

On 03.03.23 21:16, Dean Rasheed wrote:
> I think this new feature ought to be mentioned in the docs somewhere.
> Perhaps a sentence or two in the note below table 9.49 would suffice,
> since it looks like that's where jsonpath numbers are mentioned for
> the first time.

Done.  I actually put it into the data types chapter, where some other 
differences between SQL and SQL/JSON syntax were already discussed.

> In jsonpath_scan.l, I think the hex/oct/bininteger cases could do with
> a comment, such as
> 
> /* Non-decimal integers in ECMAScript; must not have underscore after radix */
> hexinteger    0[xX]{hexdigit}(_?{hexdigit})*
> octinteger    0[oO]{octdigit}(_?{octdigit})*
> bininteger    0[bB]{bindigit}(_?{bindigit})*
> 
> since that's different from the main lexer's syntax.

done

> Perhaps it's worth mentioning that difference in the docs.

done

> Otherwise, this looks good to me.

committed

On 31.03.23 16:57, Nikita Malakhov wrote:
> Sorry to bother, but there is a question on JsonPath - how many bits in 
> the JsonPath
> header could be used for the version? The JsonPath header is 4 bytes, 
> and currently
> the Version part is defined as
> #define JSONPATH_VERSION (0x01)

I don't know the answer to that.  I don't think this patch touched on 
that question at all.