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.
Attachments:
v1-0001-SQL-JSON-path-enhanced-numeric-literals.patchtext/plain; charset=UTF-8; name=v1-0001-SQL-JSON-path-enhanced-numeric-literals.patchDownload+258-15
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
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/
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.