Horton

Re: BUG #19046: Incorrect result when using json_array() with column reference in subquery combined with RIGHT JOIN

Richard Guo <guofenglinux@gmail.com>

View thread
From: Richard Guo <guofenglinux@gmail.com>
To: Tender Wang <tndrwang@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, runyuan@berkeley.edu, pgsql-bugs@lists.postgresql.org
Date: 2025-09-16T01:05:37Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Treat JsonConstructorExpr as non-strict

  2. Avoid inserting PlaceHolderVars in cases where pre-v16 PG did not.

On Fri, Sep 12, 2025 at 9:57 AM Tender Wang <tndrwang@gmail.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> 于2025年9月11日周四 11:16写道：
>> Seems like we ought to actually look at the relevant code, not
>> try to test our way to an understanding of it.

> /* JUMP to return NULL if formatted_expr evaluates to NULL */
> jumps_return_null = lappend_int(jumps_return_null, state->steps_len);
> scratch->opcode = EEOP_JUMP_IF_NULL;
> scratch->resnull = &jsestate->formatted_expr.isnull;
> scratch->d.jump.jumpdone = -1; /* set below */
> ExprEvalPushStep(state, scratch);

Yeah, this suggests that JsonExpr behaves as a strict construct.

There may be other functions that should be treated as non-strict but
currently aren't.  For now, I suggest we address JsonConstructorExpr
first.  If we encounter more such cases later, they should be
straightforward to fix as well.

- Richard