So, overall reaction to this patch: I like the approach of defining "predicate check expressions" as being a different thing from standard jsonpath expressions. However, I'm not so thrilled with just saying "don't use" one type or the other with different jsonpath functions. According to my tests, some of these functions seem to give sensible results anyway with the path type you say not to use, while some give less-sensible results, and others give errors. We ought to try to document that, and maybe even clean up the less sane behaviors. (That is, I don't feel that a docs-only patch is necessarily the thing to do here.)
As an example, @? seems to behave sanely with a standard jsonpath: 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? ---------- f (1 row) 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) Surely we're not helping anybody by leaving that behavior in place. Making it do something useful, throwing an error, or returning NULL all seem superior to this. I observe that @@ returns NULL for the path type it doesn't like, so maybe that's what to do here. (Unsurprisingly, jsonb_path_exists acts similarly.) BTW, jsonb_path_query_array and jsonb_path_query_first seem to take both types of path, like jsonb_path_query, so ISTM they need docs changes too. regards, tom lane