From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Weird special case in jsonb_concat()
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <163098.1608312033.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Dec 2020 12:20:33 -0500
Message-ID: <163099.1608312033@sss.pgh.pa.us>
Precedence: bulk

The discussion in [1] pointed out that the existing documentation
for the "jsonb || jsonb" concatenation operator is far short of
reality: it fails to acknowledge that the operator will accept
any cases other than two jsonb array inputs or two jsonb object
inputs.

I'd about concluded that other cases were handled as if by
wrapping non-array inputs in one-element arrays and then
proceeding as for two arrays.  That works for most scenarios, eg

regression=3D# select '[3]'::jsonb || '{}'::jsonb;
 ?column? =

----------
 [3, {}]
(1 row)

regression=3D# select '3'::jsonb || '[]'::jsonb;
 ?column? =

----------
 [3]
(1 row)

regression=3D# select '3'::jsonb || '4'::jsonb;
 ?column? =

----------
 [3, 4]
(1 row)

However, further experimentation found a case that fails:

regression=3D# select '3'::jsonb || '{}'::jsonb;
ERROR:  invalid concatenation of jsonb objects

I wonder what is the point of this weird exception, and whether
whoever devised it can provide a concise explanation of what
they think the full behavior of "jsonb || jsonb" is.  Why isn't
'[3, {}]' a reasonable result here, if the cases above are OK?

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/0d72b76d-ca2b-4263-8888-d6d=
fca861c51%40www.fastmail.com