Weird special case in jsonb_concat()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Weird special case in jsonb_concat()
Date: 2020-12-18 17:20:33
Message-ID: 163099.1608312033@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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=# select '[3]'::jsonb || '{}'::jsonb;
?column?
----------
[3, {}]
(1 row)

regression=# select '3'::jsonb || '[]'::jsonb;
?column?
----------
[3]
(1 row)

regression=# select '3'::jsonb || '4'::jsonb;
?column?
----------
[3, 4]
(1 row)

However, further experimentation found a case that fails:

regression=# 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-d6dfca861c51%40www.fastmail.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-12-18 17:33:12 Re: allow to \dtS+ pg_toast.*
Previous Message Bruce Momjian 2020-12-18 17:02:50 Re: Proposed patch for key managment