On Fri, Dec 2, 2022 at 5:57 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Fri, Dec 2, 2022 at 5:24 PM David G. Johnston
> <david.g.johnston@gmail.com> wrote:
> > On Fri, Dec 2, 2022 at 5:18 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> >>
> >> On Thu, Nov 24, 2022 at 8:31 AM David G. Johnston
> >> <david.g.johnston@gmail.com> wrote:
> >> > The following query produces an incorrect result. It should error (or at worse produce "false"), but it instead
produces"true" (this applies to @? too)
> >> >
> >> > select jsonb_path_exists('{"foo": true}'::jsonb, '$bar', '{}', false);
> >>
> >> Variable case is definitely broken, but I don't think other cases are
> >> broken. If we're checking for existence and there is a constant, we
> >> can immediately return true because constant exists indeed. That
> >> logic doesn't work for variable, which could be non-existent.
> >>
> >> > select jsonb_path_exists('{"foo": true}'::jsonb, '"bar"', '{}', false); -- true (bar in double quotes)
> >
> >
> > I think my issue with the constant is that the function itself is said to return whether or not the provided path
matchesthe input json. It is impossible to match the input json if there is no reference to the input json in the
jsonpathexpression. As the existing wording promises: "Checks whether the JSON path returns any item for the specified
JSONvalue" - the word item is rightly taken to mean that the path at minimum references the root (i.e., mandatory $) -
andthat any true result from exists will, if the expression is used for _match, produce the "item for the specified
JSONvalue" that was found.
> >
> > So I'll stand by my conclusion that the behavior of constants is buggy - though I suppose fixing the bug is
probablymost readily accomplished by changing the definition of what behavior we are promising and fixing up the
documentationto express that change. In short, it is really an error to not specify "$" in your expression - but if
youdon't you will simply get a true outcome for the existence test - for backward compatibility reasons.
>
> 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.
------
Regards,
Alexander Korotkov
