Re: Bug in jsonb_path_exists (maybe _match) one-element scalar/variable jsonpath handling

On Fri, Dec 2, 2022 at 10:40 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> 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:
>
> Consider: select jsonb_path_exists('{"foo":"bar"}'::jsonb, 'false');
>
> The analogous SQL query is: "SELECT * FROM table WHERE false" would indeed produce an empty set - which EXISTS would
interpretas 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
producewhen one writes a similarly nonsensical path.
 

I think this is cross-analogy existing to matching, which doesn't
work.  jsonb_path_exists() has existence symantic, while simple where
clause doesn't.

I think
"select jsonb_path_match('{"foo":"bar"}'::jsonb, 'false');"
is equivalent to
"SELECT * FROM table WHERE false;"

"select jsonb_path_exists('{"foo":"bar"}'::jsonb, '"match"');"
is equivalent to
"SELECT * FROM table WHERE EXISTS (SELECT 'match');"

------
Regards,
Alexander Korotkov