Report undefined jsonpath variable when no variables are supplied

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

@@ -2130,14 +2130,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;

src/test/regress/expected/jsonb_jsonpath.out

@@ -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.

src/test/regress/sql/jsonb_jsonpath.sql

@@ -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}');