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

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)

> select jsonb_path_match('{"foo": true}'::jsonb, '"bar"', '{}', false); -- ERROR:  single boolean result is expected
> select jsonb_path_match('{"foo": true}'::jsonb, '$bar', '{"bar":"foo"}', false); -- same error as above, as expected
>
> I expect the missing variable specification to produce jperError and the rest of the block to produce jperNotFound.  The "single boolean result expected" error seems incorrect though I'm not sure where that is coming from.  But I'm also not considering, or am even aware of, what the standard we are guided by here says should actually happen.

I think jsonb_path_match() behaves correctly, it expects jsonpatch
expression to return single boolend and throws an error otherwise.