Re: [PATCH]Fix planner's strictness check for JsonExpr

On Monday, August 24th, 2026 at 6:13 AM, Keyerror Smart <smartkeyerror(at)gmail(dot)com> wrote:

> 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:
> ```sqlSELECT 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

Hello Zhenglong Li,

I just happened upon this same issue yesterday in my testing. I was about
to start a thread when I found yours so I reviewed your patch.

The diagnosis is right, JsonExpr is not strict with respect to its PASSING
arguments, so treating it as non-strict in contain_nonstrict_functions_walker()
is the correct call, and matching CASE/COALESCE seems to me to be the natural
place for it.

So +1 from me on the approach and the patch. The conservative choice seems
right, that case is rare and the cost of getting it wrong is a wrong answer.

best.

-greg