Horton

Thread

Commits

  1. SQL JSON path enhanced numeric literals

  1. SQL JSON path enhanced numeric literals

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2023-02-27T19:13:31Z

    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.

  2. Re: SQL JSON path enhanced numeric literals

    Vik Fearing <vik@postgresfriends.org> — 2023-02-28T00:09:27Z

    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

  3. Re: SQL JSON path enhanced numeric literals

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2023-02-28T07:44:29Z

    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.

  4. Re: SQL JSON path enhanced numeric literals

    Dean Rasheed <dean.a.rasheed@gmail.com> — 2023-03-03T20:16:15Z

    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

  5. Re: SQL JSON path enhanced numeric literals

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2023-03-05T15:55:18Z

    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

  6. Re: SQL JSON path enhanced numeric literals

    Nikita Malakhov <hukutoc@gmail.com> — 2023-03-31T14:57:13Z

    Hi!

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)

Thanks!

On Sun, Mar 5, 2023 at 6:55 PM Peter Eisentraut <
peter.eisentraut@enterprisedb.com> wrote:

> 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
>
>
>
>

-- 
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/

  7. Re: SQL JSON path enhanced numeric literals

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2023-04-03T08:42:02Z

    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.