diff options
| author | Amit Langote <amitlan@postgresql.org> | 2024-10-20 12:20:55 +0900 |
|---|---|---|
| committer | Amit Langote <amitlan@postgresql.org> | 2024-10-20 12:20:55 +0900 |
| commit | 11c87216d134a606938531e52edab6189bce6c2d (patch) | |
| tree | 27c319b39948650d4232c102bc3ddb76bc9c8035 /src/backend/optimizer | |
| parent | 52475b4d30984e377542f964951bea57b0b26e92 (diff) | |
| download | postgresql-11c87216d134a606938531e52edab6189bce6c2d.tar.gz postgresql-11c87216d134a606938531e52edab6189bce6c2d.zip | |
SQL/JSON: Fix some oversights in commit b6e1157e7
The decision in b6e1157e7 to ignore raw_expr when evaluating a
JsonValueExpr was incorrect. While its value is not ultimately
used (since formatted_expr's value is), failing to initialize it
can lead to problems, for instance, when the expression tree in
raw_expr contains Aggref nodes, which must be initialized to
ensure the parent Agg node works correctly.
Also, optimize eval_const_expressions_mutator()'s handling of
JsonValueExpr a bit. Currently, when formatted_expr cannot be folded
into a constant, we end up processing it twice -- once directly in
eval_const_expressions_mutator() and again recursively via
ece_generic_processing(). This recursive processing is required to
handle raw_expr. To avoid the redundant processing of formatted_expr,
we now process raw_expr directly in eval_const_expressions_mutator().
Finally, update the comment of JsonValueExpr to describe the roles of
raw_expr and formatted_expr more clearly.
Bug: #18657
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Fabio R. Sluzala <fabio3rs@gmail.com>
Diagnosed-by: Tender Wang <tndrwang@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/18657-1b90ccce2b16bdb8@postgresql.org
Backpatch-through: 16
Diffstat (limited to 'src/backend/optimizer')
| -rw-r--r-- | src/backend/optimizer/util/clauses.c | 24 |
1 files changed, 18 insertions, 6 deletions
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c index b4e085e9d4b..8e39795e245 100644 --- a/src/backend/optimizer/util/clauses.c +++ b/src/backend/optimizer/util/clauses.c @@ -2915,13 +2915,25 @@ eval_const_expressions_mutator(Node *node, case T_JsonValueExpr: { JsonValueExpr *jve = (JsonValueExpr *) node; - Node *formatted; + Node *raw_expr = (Node *) jve->raw_expr; + Node *formatted_expr = (Node *) jve->formatted_expr; - formatted = eval_const_expressions_mutator((Node *) jve->formatted_expr, - context); - if (formatted && IsA(formatted, Const)) - return formatted; - break; + /* + * If we can fold formatted_expr to a constant, we can elide + * the JsonValueExpr altogether. Otherwise we must process + * raw_expr too. But JsonFormat is a flat node and requires + * no simplification, only copying. + */ + formatted_expr = eval_const_expressions_mutator(formatted_expr, + context); + if (formatted_expr && IsA(formatted_expr, Const)) + return formatted_expr; + + raw_expr = eval_const_expressions_mutator(raw_expr, context); + + return (Node *) makeJsonValueExpr((Expr *) raw_expr, + (Expr *) formatted_expr, + copyObject(jve->format)); } case T_SubPlan: |