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
v1-0001-Fix-strictness-check-for-JsonExpr.patch
Description: Binary data
