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

Hi Greg Burd,
Thanks for the review and the +1, and glad to hear you ran into the
same issue.
Regards,
Zhenglong Li

Greg Burd <gregburd(at)protonmail(dot)com> 于2026年10月21日周三 02:56写道：

>
> 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
>