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 по дате отправления: