From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Weird special case in jsonb_concat() |
Date: | 2020-12-19 20:35:28 |
Message-ID: | 333852.1608410128@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> 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?
Here is a proposed patch for that. It turns out that the third
else-branch in IteratorConcat() already does the right thing, if
we just remove its restrictive else-condition and let it handle
everything except the two-objects and two-arrays cases. But it
seemed to me that trying to handle both the object || array
and array || object cases in that one else-branch was poorly
thought out: only one line of code can actually be shared, and it
took several extra lines of infrastructure to support the sharing.
So I split those cases into separate else-branches.
This also addresses the inadequate documentation that was the
original complaint.
Thoughts? Should we back-patch this? The existing behavior
seems to me to be inconsistent enough to be arguably a bug,
but we've not had field complaints saying "this should work".
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-jsonb-concatenation-special-cases.patch | text/x-diff | 7.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-12-19 20:39:07 | Re: v10 release notes for extended stats |
Previous Message | Bruce Momjian | 2020-12-19 20:22:34 | Re: Proposed patch for key managment |