Re: Weird special case in jsonb_concat()

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Weird special case in jsonb_concat()
Дата
Msg-id CAFj8pRAWO2VZAC1D6+Mob2Ysi0FpMpLAn+QE=MpngZpDA2aBXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Weird special case in jsonb_concat()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


so 19. 12. 2020 v 21:35 odesílatel Tom Lane <tgl@sss.pgh.pa.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: [PATCH] Logical decoding of TRUNCATE
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: On login trigger: take three