> Hi Zhenglong,
> This is another review of CF 7186 v1 [1].
>
> Contents & Purpose
> ==================
> The patch treats JsonExpr as non-strict so that outer-join pull-up and
> STRICT SQL-function inlining preserves NULL semantics. It includes a
> regression test for the outer-join case.
>
> Initial Run
> ==================
> The patch applies cleanly to HEAD. Baseline and patched
> builds each pass all 239 core tests, and the patched build passes all 582
> make installcheck-world tests. TAP was disabled; PL/Perl, PL/Python and
> SSL was not configured.
>
> Performance
> ==================
> The conservative check prevents the safe inlining of a context-only wrapper:
>
> CREATE FUNCTION value_ctx(text) RETURNS text
> LANGUAGE sql IMMUTABLE STRICT
> AS SELECTJSONVALUE($1::jsonb,'$');
>
> SELECT sum(length(value_ctx(doc))) FROM perf;
>
> With 100,000 rows, median tested execution time increased
> from 34.9 ms to 137.3 ms, about 3.93x on macOS with JIT and parallelism
> off.
>
> Nitpicking & Conclusion
> ==================
> Nit: could you add a STRICT-inlining regression test alongside the outer-join
> test? For example:
>
> CREATE TEMP TABLE args(x integer);
> INSERT INTO args VALUES (NULL), (1);
> CREATE FUNCTION pg_temp.f(integer) RETURNS text
> LANGUAGE sql IMMUTABLE STRICT
> AS SELECTJSONVALUE('1','$'PASSING$1ASp);
>
> SELECT x, pg_temp.f(x) FROM args;
>
> For the NULL row, unpatched master returns '1'; v1 correctly returns NULL.
>
> This approach looks appropriate for the correctness fix.
> Since this is a correctness fix, preserving safe context-only inlining could be a follow-up optimization.
> +1 from me on the approach and the patch.
>
> References
> ==================
> [1] CF 7186, 2026-08-24, [PATCH]Fix planner's strictness check for JsonExpr
> https://www.postgresql.org/message-id/CAD=-kXbK=GGAAK62N-r6tKuU2dVmtJ4GvHTr=CJJGHczuuUGCQ@mail.gmail.com
>