Re: Patch: Improve Boolean Predicate JSON Path Docs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch: Improve Boolean Predicate JSON Path Docs
Дата
Msg-id 3457019.1705866206@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch: Improve Boolean Predicate JSON Path Docs  ("David E. Wheeler" <david@justatheory.com>)
Ответы Re: Patch: Improve Boolean Predicate JSON Path Docs
Список pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes:
> On Jan 20, 2024, at 12:34, Tom Lane <tgl@sss.pgh.pa.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
expectSQL standard statements evaluate the SET returned by the JSONPath statement, but predicate check expressions
don’treturn a set, but a always a single scalar value (true, false, or null). From the POV of the code expecting SQL
standardJSONPath 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patch: Improve Boolean Predicate JSON Path Docs
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: index prefetching