From: Tom Lane <tgl@sss.pgh.pa.us>
To: ma.sao@msa.hinet.net
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19454: PL/pgSQL mishandling jsonb attribute reference
In-reply-to: <19454-98a60db746b6dd22@postgresql.org>
References: <19454-98a60db746b6dd22@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 12 Apr 2026 15:45:39 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <822925.1776089551.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Apr 2026 10:12:31 -0400
Message-ID: <822926.1776089551@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/822926.1776089551%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> It appears the PL/pgSQL assignment operator :=3D fails to maintain the
> stability of a jsonb attribute reference (from a function result) during=
 a
> self-concatenation operation, whereas a SELECT wrapper forces correct
> materialization.

Your problem is operator precedence:

> v_payload :=3D v_payload || tj->'delta'; -- The problematic line
> v_payload :=3D (SELECT v_payload || (tj->'delta')); --This avoids the is=
sue.

The second formulation works because of the "extra" parentheses;
that is,
	v_payload || tj->'delta'
is parsed as
	(v_payload || tj)->'delta'
but what you need is
	v_payload || (tj->'delta')

Yeah, this isn't super intuitive, but all our non-SQL-standard
operators have the same precedence [1], so || and -> associate
left-to-right by default.

			regards, tom lane

[1] https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-PR=
ECEDENCE