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: | Raw Message | Whole Thread | 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? |