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 <[email protected]> Author: Andrey Rachitskiy <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Nikita Malakhov <[email protected]> Reviewed-by: Amit Langote <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14-16 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3640143270a9f1f115cf03a16bee3fd469ba1116 Modified Files -------------- src/backend/utils/adt/jsonpath_exec.c | 13 +++++++------ src/test/regress/expected/jsonb_jsonpath.out | 7 +++++++ src/test/regress/sql/jsonb_jsonpath.sql | 5 +++++ 3 files changed, 19 insertions(+), 6 deletions(-)
