On Fri, Dec 2, 2022 at 10:47 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> Thank you for explaining your point, but I can't agree with that. > Constant jsonpath expression is always returning item for the input > JSON value. Even despite the input value is ignored. This is > redundant case, but still correct.
Let me explain more what I do mean. In the SQL SELECT statement there is a WHERE clause. This clause should express the predicate, which should match to rows. But you're writing "WHERE 1 = 1" or "WHERE true" then all rows are matching even that no column is referenced. This is how SQL is working. And I see no reason why jsonpath should work in a different way.
I like the analogy but it seems to support my conclusion moreso than yours:
The analogous SQL query is: "SELECT * FROM table WHERE false" would indeed produce an empty set - which EXISTS would interpret as false but you want to evaluate to true
Or, "SELECT * FROM table WHERE 'banana';" which produces the same kind of error that I wish jsonb_path_exists would produce when one writes a similarly nonsensical path.
David J.
I'll probably get to a formal review of the patch - but actually I am hoping someone else more comfortable in the codebase chimes in here with an opinion. Though as I said, I'm willing to concede that the behavior should probably stay unchanged, for compatibility reasons, and we just need to decide on how to correctly document this.
