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