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 <[email protected]> 于2026年10月21日周三 02:56写道： > > On Monday, August 24th, 2026 at 6:13 AM, Keyerror Smart < > [email protected]> 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 >
