]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Report undefined jsonpath variable when no variables are supplied
authorAmit Langote <amitlan@postgresql.org>
Thu, 18 Jun 2026 06:51:49 +0000 (15:51 +0900)
committerAmit Langote <amitlan@postgresql.org>
Thu, 18 Jun 2026 06:54:16 +0000 (15:54 +0900)
The two-argument jsonb @? and @@ operators invoke the jsonpath executor
with no variable set.  In that case getJsonPathVariable() treated any
"$name" reference as JSON null and continued evaluating, instead of
reporting the variable as undefined.

This produced incorrect results -- for example '42'::jsonb @? '$"x"'
returned true -- and, for some malformed or hostile jsonpath expressions
with deeply nested predicates, allowed essentially unbounded memory
consumption that could get the backend killed by the OOM killer.

Report the undefined variable as an error in this case as well, reusing
the message already emitted when a variable is not found among supplied
variables.  This matches the behavior of v17 and later, where the
jsonpath executor was reorganized.  Stopping at the first undefined
variable reference also resolves the reported memory-growth case.

Note this is a user-visible change in the back branches: a jsonpath
expression that references a variable while no variables are supplied now
raises an error rather than silently evaluating it as NULL.  The previous
behavior was incorrect, so the change is judged worthwhile.

Bug: #19458
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Nikita Malakhov <hukutoc@gmail.com>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/19458-a69c98bc498333ba@postgresql.org
Backpatch-through: 14-16

src/backend/utils/adt/jsonpath_exec.c
src/test/regress/expected/jsonb_jsonpath.out
src/test/regress/sql/jsonb_jsonpath.sql

index f7edfb352e8cd6789732f55ba9d5d17a772fcb97..ba9bbb620674b845a78cdc0f59e43ac3612fe8a9 100644 (file)
@@ -2128,14 +2128,15 @@ getJsonPathVariable(JsonPathExecContext *cxt, JsonPathItem *variable,
        JsonbValue      tmp;
        JsonbValue *v;
 
-       if (!vars)
-       {
-               value->type = jbvNull;
-               return;
-       }
-
        Assert(variable->type == jpiVariable);
        varName = jspGetString(variable, &varNameLength);
+
+       if (!vars)
+               ereport(ERROR,
+                       (errcode(ERRCODE_UNDEFINED_OBJECT),
+                        errmsg("could not find jsonpath variable \"%s\"",
+                                       pnstrdup(varName, varNameLength))));
+
        tmp.type = jbvString;
        tmp.val.string.val = varName;
        tmp.val.string.len = varNameLength;
index 6659bc9091ac04373bf3ce28b16d13bf6c036670..eafb421c7afcf75af5182d315a6f2ed4798c54c9 100644 (file)
@@ -487,6 +487,13 @@ select * from jsonb_path_query('{"a": 10}', '$');
 
 select * from jsonb_path_query('{"a": 10}', '$ ? (@.a < $value)');
 ERROR:  could not find jsonpath variable "value"
+-- the @? and @@ operators supply no variables, so a variable reference
+-- must be reported as undefined rather than silently treated as NULL
+-- (the latter gave wrong results and could drive unbounded memory use)
+select jsonb '42' @? '$"no_such_var"';
+ERROR:  could not find jsonpath variable "no_such_var"
+select jsonb '42' @@ '$"no_such_var" == 1';
+ERROR:  could not find jsonpath variable "no_such_var"
 select * from jsonb_path_query('{"a": 10}', '$ ? (@.a < $value)', '1');
 ERROR:  "vars" argument is not an object
 DETAIL:  Jsonpath parameters should be encoded as key-value pairs of "vars" object.
index e0ce509264a9a8c5f16b3cb6254e9a2bd288fe2c..8163fc6713b8bec39abc85eb07bde9e88a3c1db8 100644 (file)
@@ -98,6 +98,11 @@ select jsonb_path_query('[1,2,3]', '$[last ? (@.type() == "string")]', silent =>
 
 select * from jsonb_path_query('{"a": 10}', '$');
 select * from jsonb_path_query('{"a": 10}', '$ ? (@.a < $value)');
+-- the @? and @@ operators supply no variables, so a variable reference
+-- must be reported as undefined rather than silently treated as NULL
+-- (the latter gave wrong results and could drive unbounded memory use)
+select jsonb '42' @? '$"no_such_var"';
+select jsonb '42' @@ '$"no_such_var" == 1';
 select * from jsonb_path_query('{"a": 10}', '$ ? (@.a < $value)', '1');
 select * from jsonb_path_query('{"a": 10}', '$ ? (@.a < $value)', '[{"value" : 13}]');
 select * from jsonb_path_query('{"a": 10}', '$ ? (@.a < $value)', '{"value" : 13}');