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

On Wed, 21 Oct 2026 14:43:04 +0800, Keyerror Smart <smartkeyerror(at)gmail(dot)com> wrote:
> Hi Greg Burd,
> Thanks for the review and the +1, and glad to hear you ran into the
> same issue.
> Regards,
> Zhenglong Li

Happy to help out Zhenglong, now we just need to get the attention
of a committer who has interest in a fix like this. They are quite
busy at the moment, so let's be patient.

-greg

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