> On 20 Apr 2026, at 18:38, Andrey Rachitskiy <pl0h0yp1@gmail.com> wrote:
>
> I propose a targeted backpatch for REL_14/15/16 in jsonpath_exec.c to align missing variable handling with newer
branchesand prevent pathological memory growth on malformed/hostile jsonpath expressions.
Hi! Thank you for the report and proposed fix. I've took a look into the
patch.
So we can use vars like this:
# SELECT jsonb_path_exists(
'{"x": 42}'::jsonb,
'$ ? ($"threshold" < 50)'::jsonpath,
'{"threshold": 10}'::jsonb -- HERE go vars
);
Operator @? is doing the same, but without supplied vars. And this thread
essentially points to buggy handling of vars:
# SELECT j @? '$"no_such_var"'
FROM (VALUES
('{"important": "data"}'::jsonb),
('42'::jsonb),
('null'::jsonb),
('false'::jsonb)
) AS t(j);
?column?
----------
t
t
t
t
(4 rows)
It basically says that path with value of var "no_such_var" exists everywhere.
I think it's a bug, but we would need a JSON Path expert here.
17+ throws an error, which seems suspicious to me too. @? is expected to
operate in silent mode. Perhaps, we should just return NULL instead of t.
By using RETURN_ERROR macro. But it might sound overly invasive for back
branches.
Even if we are going to throw an error, we can give mode details. I'd suggest
instead of "could not find jsonpath variable \"%s\"" throwing something like
"no variables supplied to reference by variable \"%s\"" or something along
those lines.
Besides this, the direction of the fix looks good to me. Thank you!
Best regards, Andrey Borodin.
