| From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
|---|---|
| To: | Chapman Flack <jcflack(at)acm(dot)org> |
| 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:16:09 |
| Message-ID: | 09B1C834-4A07-4838-854E-7007C2DF1D72@justatheory.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jun 13, 2024, at 21:58, Chapman Flack <jcflack(at)acm(dot)org> wrote:
>>>> david=# select jsonb_path_query('1', '$ >= 1');
>>>
>>> Good point. I can't either. No way I can see to parse that as
>>> a <JSON path wff>.
>>
>> Whether we note it as non-standard or not is an open question then, but it
>> does work and opens up a documentation question.
>
> Does the fact that it does work raise any potential concern that our
> grammar is nonconformant in some way that could present a headache
> somewhere else, or down the road with a later standard edition?
I believe this case is already covered in the docs as a Postgres-specific feature: predicate path expressions.
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.
D
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chapman Flack | 2024-06-14 02:31:02 | Re: jsonpath: Missing Binary Execution Path? |
| Previous Message | David G. Johnston | 2024-06-14 02:14:36 | Re: jsonpath: Missing Binary Execution Path? |