| From: | Keyerror Smart <smartkeyerror(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | [PATCH]Fix planner's strictness check for JsonExpr |
| Date: | 2026-08-24 10:13:28 |
| Message-ID: | CAD=-kXbK=GGAAK62N-r6tKuU2dVmtJ4GvHTr=CJJGHczuuUGCQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi, while testing JSON PASSING, I ran into a minor strictness handling bug.
JsonExpr is implicitly treated as a strict node in
contain_nonstrict_functions_walker(), but it
isn't actually strict with respect to its PASSING arguments. For instance:
```sql
SELECT v FROM (VALUES (1)) a
LEFT JOIN (SELECT json_value('1', '$' PASSING y AS p) v
FROM (VALUES (1),(2)) b(y)) ss ON false;
-- Return 1, not correct
-- pull-up plan
EXPLAIN (COSTS OFF)
SELECT v FROM (VALUES (1)) a
LEFT JOIN (SELECT json_value('1', '$' PASSING y AS p) v
FROM (VALUES (1),(2)) b(y)) ss ON false;
QUERY PLAN
------------------------------------
Nested Loop Left Join
Disabled: true
Join Filter: false
-> Result
-> Result
Replaces: Scan on *VALUES*
One-Time Filter: false
Optimizer: Postgres-based planner
(8 rows)
-- Using OFFSET 0 to prevent pulling up
SELECT v FROM (VALUES (1)) a
LEFT JOIN (SELECT json_value('1', '$' PASSING y AS p) v
FROM (VALUES (1),(2)) b(y) OFFSET 0) ss ON false;
-- Return NULL, correct
```
Fix by treating JsonExpr as non-strict, as we already do for CASE,
COALESCE and similar constructs. This is conservative -- a JsonExpr
with no PASSING arguments and constant ON EMPTY / ON ERROR behaviors
is in fact strict -- but distinguishing those cases hardly seems worth
the trouble.
Patch attached.
Regards,
Zhenglong Li
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-strictness-check-for-JsonExpr.patch | application/octet-stream | 4.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhijie Hou (Fujitsu) | 2026-08-24 10:33:46 | RE: apply worker misses closing partition leaves |
| Previous Message | Alexander Lakhin | 2026-08-24 10:00:01 | Re: Changing the state of data checksums in a running cluster |