From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Weird special case in jsonb_concat() |
Date: | 2020-12-20 06:32:48 |
Message-ID: | CAFj8pRAWO2VZAC1D6+Mob2Ysi0FpMpLAn+QE=MpngZpDA2aBXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
so 19. 12. 2020 v 21:35 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> 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".
>
+1
Pavel
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-12-20 07:04:04 | Re: On login trigger: take three |
Previous Message | Noah Misch | 2020-12-20 04:13:19 | Re: [PATCH] Logical decoding of TRUNCATE |