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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tender Wang <tndrwang(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, runyuan(at)berkeley(dot)edu, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19046: Incorrect result when using json_array() with column reference in subquery combined with RIGHT JOIN
Date: 2025-09-16 01:05:37
Message-ID: CAMbWs48QUhcvoPCDkR1xujcPG8AqiyqygfOicLYmaF94c1Lrcw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Sep 12, 2025 at 9:57 AM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-09-16 02:08:40 Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.
Previous Message Thomas Munro 2025-09-15 23:19:24 Re: BUG #19052: failing to install on Windows if user path contains Chineese/Korean characters