agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Report undefined jsonpath variable when no variables are supplie 3+ messages / 1 participants [nested] [flat]
* pgsql: Report undefined jsonpath variable when no variables are supplie @ 2026-06-18 06:52 Amit Langote <amitlan@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Amit Langote @ 2026-06-18 06:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 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(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Report undefined jsonpath variable when no variables are supplie @ 2026-06-18 06:56 Amit Langote <amitlan@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Amit Langote @ 2026-06-18 06:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8af173e2837084c462a5ee3478d1dbcd7cc9b1d6 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(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Report undefined jsonpath variable when no variables are supplie @ 2026-06-18 06:57 Amit Langote <amitlan@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Amit Langote @ 2026-06-18 06:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1daeef6e0db548f81543065a535ce1b3ec62fe26 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(-) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-06-18 06:57 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-06-18 06:52 pgsql: Report undefined jsonpath variable when no variables are supplie Amit Langote <amitlan@postgresql.org> 2026-06-18 06:56 pgsql: Report undefined jsonpath variable when no variables are supplie Amit Langote <amitlan@postgresql.org> 2026-06-18 06:57 pgsql: Report undefined jsonpath variable when no variables are supplie Amit Langote <amitlan@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox