Re: Patch: Improve Boolean Predicate JSON Path Docs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: Erik Wienhold <ewie(at)ewie(dot)name>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Patch: Improve Boolean Predicate JSON Path Docs
Date: 2024-01-21 19:43:26
Message-ID: 3457019.1705866206@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David E. Wheeler" <david(at)justatheory(dot)com> writes:
> On Jan 20, 2024, at 12:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It will take a predicate, but seems to always return true:
>>
>> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] < 5' ;
>> ?column?
>> ----------
>> t
>> (1 row)
>>
>> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] > 5' ;
>> ?column?
>> ----------
>> t
>> (1 row)

> Just for the sake of clarity, this return value is “correct,” because @? and other functions and operators that expect SQL standard statements evaluate the SET returned by the JSONPath statement, but predicate check expressions don’t return a set, but a always a single scalar value (true, false, or null). From the POV of the code expecting SQL standard JSONPath results, that’s a set of one. @? sees that the set is not empty so returns true.

I don't entirely buy this argument --- if that is the interpretation,
of what use are predicate check expressions? It seems to me that we
have to consider them as being a shorthand notation for filter
expressions, or else they simply do not make sense as jsonpath.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2024-01-21 19:50:17 Re: index prefetching
Previous Message Tom Lane 2024-01-21 19:34:19 Re: Patch: Improve Boolean Predicate JSON Path Docs