From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | ❓ JSON Path Dot Precedence |
Date: | 2024-04-07 16:13:45 |
Message-ID: | 2F757EB8-AEB9-49E8-A2C6-613E06BA05D4@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Hackers,
A question about the behavior of the JSON Path parser. The docs[1] have this to say about numbers:
> Numeric literals in SQL/JSON path expressions follow JavaScript rules, which are different from both SQL and JSON in some minor details. For example, SQL/JSON path allows .1 and 1., which are invalid in JSON.
In other words, this is valid:
david=# select '2.'::jsonpath;
jsonpath
----------
2
But this feature creates a bit of a conflict with the use of a dot for path expressions. Consider `0x2.p10`. How should that be parsed? As an invalid decimal expression ("trailing junk after numeric literal”), or as a valid integer 2 followed by the path segment “p10”? Here’s the parser’s answer:
david=# select '0x2.p10'::jsonpath;
jsonpath
-----------
(2)."p10"
So it would seem that, other things being equal, a path key expression (`.foo`) is slightly higher precedence than a decimal expression. Is that intentional/correct?
Discovered while writing my Go lexer and throwing all of Go’s floating point literal examples[2] at it and comparing to the Postgres path parser. Curiously, this is only an issue for 0x/0o/0b numeric expressions; a decimal expression does not behave in the same way:
david=# select '2.p10'::jsonpath;
ERROR: trailing junk after numeric literal at or near "2.p" of jsonpath input
LINE 1: select '2.p10'::jsonpath;
Which maybe seems a bit inconsistent.
Thoughts on what the “correct” behavior should be?
Best,
David
[1]: https://www.postgresql.org/docs/devel/datatype-json.html#DATATYPE-JSONPATH
[2]: https://tip.golang.org/ref/spec#Floating-point_literals
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-04-07 16:28:56 | Re: Cluster::restart dumping logs when stop fails |
Previous Message | Erik Wienhold | 2024-04-07 14:56:53 | Re: CASE control block broken by a single line comment |