| From: | Chapman Flack <jcflack(at)acm(dot)org> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: jsonpath: Missing Binary Execution Path? |
| Date: | 2024-06-14 02:31:02 |
| Message-ID: | 666BAB66.1020000@acm.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/13/24 22:16, David E. Wheeler wrote:
> But even inside filters I don’t understand why &&, ||, at least,
> currently only work if their operands are predicate expressions.
> Seems weird; and your notes above suggest that rule applies only to !,
> which makes slightly more sense.
It's baked right into the standard grammar: || can only have a
<JSON boolean conjunction> on its right and a <JSON boolean disjunction>
on its left.
&& can only have a <JSON boolean negation> on its right and a
<JSON boolean conjunction> on its left.
The case for ! is even more limiting: it can't be applied to anything
but a <JSON delimited predicate>. That can be either the exists predicate,
or, any other <JSON path predicate> but wrapped in parentheses.
The language seems sort of gappy in the same way XPath 1.0 was. XPath 2.0
became much more consistent and conceptually unified, only by that time,
XML was old school, and JSON was cool, and apparently started inventing
a path language.
Regards,
-Chap
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2024-06-14 02:42:25 | Re: race condition in pg_class |
| Previous Message | David E. Wheeler | 2024-06-14 02:16:09 | Re: jsonpath: Missing Binary Execution Path? |